<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
    <title>SIF Implementation Specification 2.2 - Architecture</title>
    <link rel="stylesheet" type="text/css" href="include/document.css" />
    <link rel="stylesheet" type="text/css" href="include/specification.css" />
  </head>
  <body>
    <div class="navigation" id="topnavigation">
      <a href="index.html">home</a>
      <a href="Introduction.html">previous</a>
      <a href="Messaging.html">next</a>
      <a href="index.html#contents">table of contents</a>
      <hr />
    </div>
    <a name="Architecture" />
    <h1>3 Architecture</h1>
    <a name="Assumptions" />
    <h2>3.1 Assumptions</h2>
    <p>The following assumptions are made of non-technical readers of this specification, especially end users undertaking SIF implementations:</p>
    <ul>
      <li>A passing familiarity with <a href="References.html#XML">[XML]</a> and its use.  Readers
				lacking this prerequisite are referred to <a href="References.html#XMLINTRO">[XMLINTRO]</a> and other
				ubiquitous materials.</li>
      <li>A familiarity with HTTP and HTTPS and the security, encryption and authentication features of the latter.
				These should be familiar to World Wide Web users.</li>
      <li>A good understanding of the educational data that applications in an implementation store and would benefit from sharing, and the ability to identify equivalents in the 
				SIF Data Model.</li>
    </ul>
    <p>They should also be aware that there are numerous third-party products and services available to aid in SIF implementation and 
			integration.</p>
    <p>Technical readers implementing SIF software and software solutions, particularly those implementing SIF Agents and Zone Integration Servers 
			from scratch as opposed to using or building upon third-party products and services, should have an understanding of:</p>
    <ul>
      <li>The subset of HTTP 1.1 <a href="References.html#RFC2616">[RFC 2616]</a> referenced in the SIF HTTPS and SIF HTTP Transport Layers.</li>
      <li>Those portions of TLS 1.0 <a href="References.html#RFC2246">[RFC 2246]</a>, SSL 3.0 <a href="References.html#SSL3">[SSL3]</a> and SSL 2.0
				 <a href="References.html#SSL3">[SSL2]</a> that are applicable to the SIF HTTPS and SIF HTTP Transport Layers, including associated
				encryption, signature and authentication algorithms, including the use of X.509 certificates.</li>
      <li>XML 1.0 <a href="References.html#XML">[XML]</a> and its references to Unicode and the UTF-8 Encoding.</li>
      <li>The role and use of namespaces in XML <a href="References.html#XMLNS">[XMLNS]</a>.</li>
      <li>Accessing XML elements/attributes using XPath <a href="References.html#XPATH">[XPATH]</a>.</li>
      <li>XML Schema data types and structures <a href="References.html#XMLSCHEMA">[XMLSCHEMA]</a>.</li>
      <li>Relational database and message queue concepts.</li>
    </ul>
    <p>It is furthermore assumed that implementers have at their disposal or can implement:</p>
    <ul>
      <li>Adequate XML tools (e.g. parsers; parsers that can validate using XML Schema, if desired; simple XPath evaluators) as they develop SIF-compliant 
				software.</li>
      <li>Implementations of HTTP(S) that support the SIF HTTPS Transport Layer, and optionally, the SIF HTTP Transport Layer.</li>
    </ul>
    <a name="NotesOnRelatedTechnologies" />
    <h3>3.1.1 Notes on Related Technologies</h3>
    <p>
					Implementers are referred to <a href="NotesOnRelatedTechnologies.html">Notes on Related Technologies</a>, which highlights technologies
					leveraged within SIF or related to SIF, either in their entirety or as a subset.  This partially normative appendix points out specifics casual readers
					of referenced documents on these technologies must not ignore when implementing SIF Zone Integration Servers and Agents.
				</p>
    <a name="Concepts" />
    <h2>3.2 Concepts</h2>
    <p>This section presents the ideas behind the implementation of SIF, including the application and data models on which it is based. 
			It serves as a precursor to further descriptions in following sections.</p>
    <a name="DataModel" />
    <h3>3.2.1 Data Model</h3>
    <p>The data that can be exchanged in SIF is defined using a series of data objects. 
				These objects are expressed using <a href="References.html#XML">[XML]</a> and are defined structurally by this document and associated schemas,
				with this document and supporting documentation defining the semantics behind the exchange of individual data objects.
				<code>StudentPersonal</code>, <code>StudentSchoolEnrollment</code> and <code>StaffPersonal</code> are three of the many predefined data objects.</p>
    <a name="ZoneArchitecture" />
    <h3>3.2.2 Zone Architecture</h3>
    <p>Although there are many variations of SIF topographies, the common feature is that a number of applications wish to share data. 
				All SIF implementations, regardless of their complexity, consist of one or more applications with their associated agents 
				communicating via a Zone Integration Server (ZIS).</p>
    <p>One typical use of SIF is to connect products from various vendors together within a single school. 
				These applications could include a student information application, a food service program, and a library automation application. 
				Each of these applications has a vendor-provided interface program called an Agent.</p>
    <p>Since the same school shares these applications, it makes sense to group them together into a logical entity. 
				This entity is referred to as a Zone and is managed by a Zone Integration Server (ZIS).</p>
    <p>There are no predefined sizes for zones, so a zone can be as large or small as required in order to meet the needs of the customer.</p>
    <p>An application relies on its agent to exchange data using a predefined data model. 
				Agents then communicate with other agents using the ZIS as a routing resource. 
				The ZIS also provides access control so the customer can control which applications have access to which SIF data.</p>
    <a name="Contexts" />
    <h4>3.2.2.1 Contexts</h4>
    <p>
					The Zone is the primary means of partitioning data, applications, and policies. 
					Zones are typically organized around geographic boundaries (e.g. school, district, region, state) or functional boundaries 
					(e.g. horizontal integration, student locator services, data warehousing and reporting services).
					A SIF Context offers the ability to further partition the data within a Zone, to offer different perspectives of the data based on customer
					needs and application abilities. For example, while a student information system typically serves as the source for student-related data 
					in the default
					context of a zone that integrates applications in a school or district, a data warehouse might better be suited to provide 
					a historical or longitudinal perspective of that exact same student data in a different context, a context more suited to the 
					reporting and data warehousing needs of an implementation.  
					Contexts enable customers and system integrators to work with data in new ways while retaining the 
					zone topologies commonly in use in implementations.			
					</p>
    <p>
In addition to offering different perspectives on a zone's data, contexts allow two or more agents to
register as a provider of the same object type within a zone. This may lead to future solutions built around
contexts; for example, to better define how systems that publish similar objects cooperate in the same zone
(e.g. student information systems and special education packages). Contexts also make it easier to apply a
different set of business rules to different audiences.
Unlike zones, which can be named and assembled in a variety of ways at the discretion of system integrators,
contexts are to be treated as a part of the specification. SIFA sanctions contexts
and provides documentation that defines each context's purpose and any associated
message choreographies and business rules for it.  Contexts defined by SIFA have context names that begin with
<code>SIF_</code> and the default context for a zone is named <code>SIF_Default</code>.  It is <span class="rfc2119">RECOMMENDED</span> 
that all ZIS implementations support SIFA-defined contexts
as they are introduced; support for user-defined contexts is strictly implementation dependent, and agents are discouraged
from relying on ad hoc or user-defined contexts.
</p>
    <a name="InfrastructureAndMessaging" />
    <h3>3.2.3 Infrastructure and Messaging</h3>
    <p>Agents share data in a Zone via two models, the Publish/Subscribe model and the Request/Response model.  Agents publish data changes
				of interest to subscribers by sending a <code>SIF_Event</code> message to the ZIS.  Agents can also request or query data from
				other agents in a Zone by sending a <code>SIF_Request</code> message to an Agent, eventually being sent one or more <code>SIF_Response</code>
				messages in return.  This exchange of messages over a SIF-defined transport layer, SIF HTTPS or SIF HTTP, is the primary feature
				that defines the SIF Infrastructure.  Every message exchanged over this infrastructure is wrapped inside a <code>SIF_Message</code> and
				contains a <code>SIF_Header</code> element that specifies the source of the message and optional security, destination and
				context information.  In addition to the messages exchanged between Agents via the ZIS, the SIF Infrastructure defines a number of messages
				that are exchanged between Agent and ZIS, and between ZIS and Push-mode Agent—these serve primarily to register various Agent settings
				at the ZIS and to support the exchange of messages between Agents.</p>
    <a name="DataProvisionARequestResponseModel" />
    <h3>3.2.4 Data Provision: A Request/Response Model</h3>
    <p>When an application (the <em>Requester</em>) wants to gather data from a specific data object, 
				a <code>SIF_Request</code> message is sent to ZIS.  The application may direct this request to a given <em>Responder</em> by specifying
				an Agent ID in the <code>SIF_DestinationId</code> element of <code>SIF_Header</code>.  
				In most cases, however, the <code>SIF_DestinationId</code> element 
				is omitted in which case the ZIS routes the request to the default responder, 
				or <em>Provider</em>, for the data object of interest.  Agents register as 
				Providers with the ZIS using either the <code>SIF_Provision</code> or <code>SIF_Provide</code> message.</p>
    <p>There is a single Provider per object per context per zone. 
				There may be multiple Responders for a given object in a zone context.</p>
    <p>In order to maintain control over what data is exchanged
over the zone and who exchanges it, the ZIS must provide an access
control system that limits who can provide, request, and respond to requests
for which data objects. The access control system must maintain policies for each registered application.</p>
    <p>If the requester knows or wants to control who the responder
will be, it must place the responder's agent identifier in the
<code>SIF_DestinationId</code> element of the header of the <code>SIF_Request</code> message. The
ZIS will examine the <code>SIF_Request</code> message's header. If a <code>SIF_DestinationId</code>
element is present, the ZIS must route the <code>SIF_Request</code> to the specified agent/application subject to the limitations 
imposed by the access control security policies for the zone. For instance, even though an application specifies that it wishes a specified application to respond, the zone security policy may prohibit the specified application from generating <code>SIF_Response</code> messages.</p>
    <p>An application that wants to provide access to the data it
contains via SIF may function as a responder. Such applications will
support one or more SIF data objects. The application listens for
<code>SIF_Request</code> messages for the objects that it supports. When it receives a
<code>SIF_Request</code> for a supported object, the application will generate one or more
<code>SIF_Response</code> messages containing the application's data, which will be routed
by the ZIS to the requester. The responder must place the requester's agent identifier in the <code>SIF_DestinationId</code> element of the header for each <code>SIF_Response</code> message generated.</p>
    <p>When an application receives a <code>SIF_Request</code> for a data object
that it does not support, it must return a <code>SIF_Response</code> message with the <code>SIF_Error</code> element populated to indicate the nature of the error (invalid object), a <code>SIF_PacketNumber</code> of <code>1</code> and the <code>SIF_MorePackets</code> element set to indicate that no further packets will be sent in response to the <code>SIF_Request</code>.</p>
    <a name="EventReportingAPublishSubscribeModel" />
    <h3>3.2.5 Event Reporting: A Publish/Subscribe Model</h3>
    <p>Applications propagate data updates by publishing <code>SIF_Event</code>
messages for the SIF data objects that are being added, changed, or
deleted. In order for an application to receive these <code>SIF_Event</code>s,
subscriptions for the SIF data objects of interest must be entered at the ZIS. 
This subscription process is performed when an application sends a <code>SIF_Provision</code> message or one or more <code>SIF_Subscribe</code> messages to the ZIS. 
Once the subscriptions are entered, any <code>SIF_Event</code>s for those objects received by the ZIS will be routed to the list of subscribers for those objects.</p>
    <p>Once an application successfully sends a <code>SIF_Event</code> to the ZIS, the ZIS is responsible for delivering that <code>SIF_Event</code> to the subscribing parties 
without any further communication to the <code>SIF_Event</code> originator. 
The <code>SIF_Event</code> originator does not know how many applications, if any, receive the <code>SIF_Event</code>. 
No notifications are provided to the originator to indicate whether a <code>SIF_Event</code> was delivered to a subscriber or not.</p>
    <p>The ZIS must maintain an access control system that limits who can publish and subscribe to events for which data objects.</p>
    <p>Before an application can utilize the services of the ZIS,
the application must register itself by sending a <code>SIF_Register</code> message
to the ZIS. Once registered, an application does not have to
perform any additional registration with the ZIS in order to be a publisher of
<code>SIF_Event</code> data. Any application that has registered itself with the ZIS may publish <code>SIF_Event</code>s subject 
to the limitations imposed by the access control security policies for the zone.
It is recommended that event publishers register their ability to publish events by using the <code>SIF_Provision</code> message.</p>
    <p>Multiple applications may publish <code>SIF_Event</code> messages for a given data object.</p>
    <p>The application that is registered as the Provider for a
given data object must be able to subscribe to <code>SIF_Event</code>s for
that object but the application is not required to subscribe to <code>SIF_Event</code>s in a given SIF implementation.</p>
    <p>An application that has subscribed to a <code>SIF_Event</code> must
attempt to process the <code>SIF_Event</code> according to the business rules of the
application. If the <code>SIF_Event</code> contains insufficient information or
information that is inconsistent with the application's business rules, the
application may ignore the message.</p>
    <p>If an application publishes a <code>SIF_Event</code> as a result of
changing the data within the application and the ZIS rejects the <code>SIF_Event</code>
message, it is recommended that the application rolls back or cancels
the changes that were made, but the application does not have to roll back the changes. 
For example, an application may attempt to add a new student and publish a <code>SIF_Event</code> to reflect the addition. 
If the application does not have permission to publish <code>SIF_Event</code> messages for that type of object, the <code>SIF_Event</code> is rejected. 
The application does not have to remove the newly added student from its local database.</p>
    <a name="CommunicationAnAsynchronousModel" />
    <h3>3.2.6 Communication: An Asynchronous Model</h3>
    <p>In order to ensure scalability and reliability, SIF requires that its request/response and publish/subscribe models be asynchronous in nature. Once a ZIS synchronously acknowledges receipt of a <code>SIF_Event</code>, <code>SIF_Request</code> or <code>SIF_Response</code> with the return of a successful <code>SIF_Ack</code>, an agent cannot be assured that these messages will immediately be delivered to subscribers, providers/responders or requesters, respectively, or that it will receive an immediate <code>SIF_Response</code> to any submitted <code>SIF_Request</code>.</p>
    <p>The asynchronous communication model can be likened to communicating with someone via e-mail or through the postal office: an individual sends the message, but does not know when it will be received, much less when the receiver will respond.</p>
    <p>By requiring asynchronous communications, a SIF implementation can exploit software designs that achieve high scalability and reliability. 
For example, even if an agent is not currently connected to a Zone, another application's agent can still send messages to that agent knowing that the ZIS will deliver those messages as soon as the agent is available.</p>
    <p>In contrast to the asynchronous communication model, most agent-to-ZIS and ZIS-to-agent communication—over currently defined transport layers—is synchronous in nature. Any time an agent sends a <code>SIF_Message</code> to a ZIS, the agent waits for a <code>SIF_Ack</code> to be returned from the ZIS to acknowledge receipt of the message. Once acknowledged, the ZIS guarantees future delivery of <code>SIF_Event</code>, <code>SIF_Request</code> and <code>SIF_Response</code> messages, barring certain error conditions. For messages not directly related to the request/response and publish/subscribe models, the acknowledgement from the ZIS also indicates successful completion of operations related to registration, subscription, provision and system control operations. Relatedly, when a ZIS contacts an agent in Push mode, the ZIS waits for a <code>SIF_Ack</code> to be returned from the agent to acknowledge successful delivery of the message currently pending for the agent.</p>
    <a name="SecurityModel" />
    <h3>3.2.7 Security Model</h3>
    <p>The security model of SIF centers around three areas: encryption, authentication and access control. SIF provides application agents the ability to specify the encryption and authentication requirements for all other agents that eventually come into contact with their sensitive data. Various communication protocols over which SIF data may be transferred, including SIF HTTPS, provide built-in support for easing the implementation details of guaranteeing encryption and authentication requirements. In addition, access control at the ZIS allows a zone administrator complete control over which agents are allowed to communicate which data to other agents.</p>
    <p>As SIF HTTPS is the default communication protocol that all agents and ZIS implementations must support, many of the encryption and authentication levels specified in this document are tailored to the encryption and authentication algorithms currently defined within SIF HTTPS. When a ZIS implementation supports other communication protocols, the ZIS must guarantee that these levels are accurately reflected and adhered to when communicating with agents that support these same protocols.</p>
    <a name="Encryption" />
    <h4>3.2.7.1 Encryption</h4>
    <p>Encryption provides the mechanism to ensure that only the sender and receiver of a message can view the message contents. In a totally secure model, all communications between agent and ZIS will be encrypted. The SIF HTTPS protocol, which must be supported by all agents and ZIS implementations, is a secure transport and provides encryption of the data being exchanged.</p>
    <p>If additional communication protocols, or transports, are used, it is important to know if these transports are secure to avoid exposing sensitive data. SIF provides a method for an agent to specify to the ZIS how secure the channel between the ZIS and other agents must be when ultimately delivering the originating agent's sensitive data. ZIS implementations must guarantee the requested security levels when communicating with recipient agents, regardless of which transport is in use. If a ZIS is unable to ensure these security levels when communicating with a recipient agent, the ZIS must not transport the message across the insufficiently secure channel. It is recommended that the ZIS log the inability to deliver the message to the recipient agent due to security requirements.</p>
    <p>The responsibility for guaranteeing the security of data that an originating agent transfers to the ZIS lies ultimately with the originating agent, or zone administrators. For example, if the originating agent requires a very secure channel for a given message, it should not intentionally or inadvertently communicate that message to the ZIS over an insecure or insufficiently secure channel, should the ZIS support such channels. At that point, the data has already been communicated insecurely. Zone administrators can prevent such occurrences by configuring the ZIS and agents within the zone such that a minimum security level is maintained, below which communication is impossible.</p>
    <p>In many cases, the establishment of a secure channel and encryption can be delegated to the transport layer.</p>
    <a name="AuthenticationAndValidation" />
    <h4>3.2.7.2 Authentication and Validation</h4>
    <p>The role of authentication is to provide a means to ensure that the author of a message is the actual author. Authentication guards against a situation where a foreign agent claims to be a legitimate zone participant and fakes a message to gain access or alter the SIF data.</p>
    <p>Another important role of authentication is to provide the ability to detect that each message that passes through the Zone 
arrives at its destination unaltered by other intermediaries.</p>
    <p>Authentication support is optional but highly recommended.</p>
    <a name="AccessControl" />
    <h4>3.2.7.3 Access Control</h4>
    <p>SIF must be customizable for specific deployments. This particularly applies to customization for the security policies. 
For example, a SIF administrator can specify which applications can participate in the SIF deployment, which data objects each application can provide or request, and what events each application can produce and receive.</p>
    <p>The access control requirements are discussed more fully under ZIS Requirements.</p>
    <a name="SIFArchitecture" />
    <h2>3.3 SIF Architecture</h2>
    <p>This section describes the architecture and components that make up SIF. 
			It presents high-level functional requirements for each component and interfaces between them.  More detail
			on particular requirements and interfaces may be found in <a href="Messaging.html">Messaging</a> and <a href="Infrastructure.html">Infrastructure</a>.
		</p>
    <a name="ArchitecturalComponents" />
    <h3>3.3.1 Architectural Components</h3>
    <p>
					A SIF Zone is a distributed networking system that consists of a Zone Integration Server (ZIS) and one or more integration Agents.
					The size of a zone is flexible and could consist of a single building, school, a small group of schools, a district, a region, a state, a nation, etc.
					SIF is a scalable solution for data exchange.  A SIF Implementation consists of one or more SIF Zones deployed and configured to meet 
					customer data sharing and reporting needs.
				</p>
    <p>A Zone Integration Server is a program that provides integration services to all the agents registered with it so that they can
				provide data, subscribe to events, publish events, request data, and respond to requests. 
				It is responsible for all access control and routing within the Zone.</p>
    <p>Each application requires an agent, which typically is provided by the application vendor, to communicate with other applications via the ZIS and their respective agents. For example, a school may use a student information application, a food service application, and a library automation application. 
				Each of these applications must have an agent that acts as a go-between between the application and the Zone Integration Server.</p>
    <p>In SIF, an agent never communicates with another agent directly. 
				Instead, each agent communicates with the ZIS as a trusted intermediary that brokers the exchange of data with other agents. 
				Having the ZIS manage routing responsibilities allows complex communications to occur between agents that have no direct information about each other and that
				may or may not be available for communication at any given point in time. 
				</p>
    <p>The following diagram illustrates a typical single-zone SIF implementation for a school.</p>
    <a name="Figure3311SingleZoneSchoolSIFImplementation" />
    <p>
      <img src="images/zone.jpg" alt="" title="Single-Zone School SIF Implementation" />
    </p>
    <span class="caption">Figure 3.3.1-1: Single-Zone School SIF Implementation</span>
    <p>A zone is often defined according to physical boundaries; 
				for example, a zone can consist of all the applications that are connected over a private network and managed by one organization, such as a school. 
				Security, scalability, and manageability requirements can also influence the decision of how zones are designed and configured. 
				</p>
    <p>Zones are a flexible and powerfully creative tool for meeting the data exchange and reporting needs of users; zones can be as varied as the customers
				in the education marketplace.  While a single school zone may meet the needs of a single school, SIF implementations can scale to meet the needs of 
				specific end users through the use of multiple zones, sometimes managed by different ZIS implementations.  Two examples of many multiple-zone implementation
				design patterns are included here for illustration.</p>
    <p>In the first, the data exchange needs of a district are met through the use of four zones, one for the district, and three for schools within the district:
				elementary, middle and high school.  Here a student information system provides its complete set of district-wide data to a district zone, while providing
				school-based views of and access to that data in the individual school zones.  Library systems in this implementation are school-based, while the food
				services system, like the SIS, is district-based.</p>
    <a name="Figure3312MultipleZoneDistrictSIFImplementation" />
    <p>
      <img src="images/district-multi.jpg" alt="" title="Multiple-Zone District SIF Implementation" />
    </p>
    <span class="caption">Figure 3.3.1-2: Multiple-Zone District SIF Implementation</span>
    <p>The second example illustrates an agent communicating in both a district and a state zone.  This agent could be associated with many different
				types of applications, including a SIS or data warehouse, reporting date up to the state, or an application that supports <code>StudentLocator</code>, managing
				state-level student identifiers, and so on.
			</p>
    <a name="Figure3313MultipleZoneStateSIFImplementation" />
    <p>
      <img src="images/state.jpg" alt="" title="Multiple-Zone State SIF Implementation" />
    </p>
    <span class="caption">Figure 3.3.1-3: Multiple-Zone State SIF Implementation</span>
    <p>Multiply the district portion of this diagram by dozens or hundreds of districts, each with its own local zone or configuration of zones, and the distributed scalability of SIF using
				zones is readily apparent.</p>
    <a name="NamingConventionsForAgentsAndZoneIntegrationServers" />
    <h3>3.3.2 Naming Conventions for Agents and Zone Integration Servers</h3>
    <p>SIF requires that each agent and ZIS be identified with a distinct case-sensitive identifier that is unique within a zone. 
				This identifier is carried inside the <code>SIF_SourceId</code> element of the <code>SIF_Header</code> included in each SIF message and is used, among other
				things, at the ZIS to reference access control permissions of each agent within the zone. 
				It is recommended that agent and ZIS implementations have user-configurable identifiers in order for zone administrators 
				to maintain unique identifiers within the zone.</p>
    <p>The identifier should be descriptive of the role of the application in the zone.  For example, the library automation
agent for Ramsey Elementary might carry the identifier RamseyLib instead
of the less descriptive CC41Agent. The Zone Integration Server for
Ramsey might be known as RamseyZIS.</p>
    <a name="ObjectIdentifiers" />
    <h3>3.3.3 Object Identifiers</h3>
    <p>
					Data objects and the data local to an application that map to these objects often must be retrieved by a unique identifier.  Likewise there often
					exist relationships between data objects that require a unique key or identifier for efficient look-up of related data.  SIF provides these keys
					or unique identifiers through object identifiers, also known as RefIds or GUIDs thanks to SIF naming conventions and the
					type of identifiers used in SIF, respectively.
					The <code>StudentPersonal</code> object, for instance, carries detailed information about a student, 
					and most agents that manage or require student information
					reference the data stored in this object and often map the <code>RefId</code> of <code>StudentPersonal</code> to locally stored data, or request <code>StudentPersonal</code> objects
					from the zone by <code>RefId</code>.  Objects often carry an attribute that identifies a particular object instance; this attribute is named <code>RefId</code>.
					It is imperative that <code>RefId</code>s not clash with any other <code>RefId</code>. This is especially relevant when an agent manages a database comprised of a mix of objects;
					for example, a library database containing patrons, which are a mix of both students and staff.  To virtually eliminate the possiblity of duplicate object 
					identifiers and to provide a consistent, decentralized way of generating these identifiers, SIF
					requires the use of a globally unique identifier (GUID) that <span class="rfc2119">MUST</span> be generated per published algorithms 
					<a href="References.html#RFC4122">[RFC 4122]</a> whenever a <code>RefId</code> is used.
					GUIDs in SIF have their own format; they <span class="rfc2119">MUST</span> be 32 characters long and contain only valid upper-case hexadecimal 
					characters (0-9, A-F) with no spaces or punctuation.
				</p>
    <p>
					Object identifiers do not have to appear on any customer screens and they do not replace any identifiers currently in use by applications.
					Applications and application users users can still reference data as they always have.
					The GUID provides an additional key, which becomes the SIF primary key that agents use to reference an object within SIF.
				</p>
    <p>As stated, object identifiers are also used to represent telationships between objects.  Where referenced, <code>RefId</code> is typically prefixed
				with the object name, e.g. <code>StudentPersonalRefId</code> in <code>StudentPicture</code> refers to the <code>RefId</code> of the <code>StudentPersonal</code> object corresponding
				to the student photographede.g. <code>LearnerPersonalRefId</code> in <code>LearnerSchoolEnrolment</code> refers to the <code>RefId</code> of the <code>LearnerPersonal</code> object corresponding
				to the enrolled learner.  Other more complex conventions surrounding object identifiers and RefIds can be found in <a href="DataModel.html">Data Model</a>.
				</p>
    <a name="Persistence" />
    <h4>3.3.3.1 Persistence</h4>
    <p>When used as identifiers for objects that persist over time—take for instance the <code>StudentPersonal</code> object that
					represents a student in a Zone—it is SIF's intent that object identifiers not change over time.  The <code>RefId</code> attribute
					for John Doe in first grade should have the same value when John Doe is in second grade, in middle school or in high school.  This
					persistence of object identifiers enables longitudinal tracking of data within SIF, especially where there exist no locally
					unique identifiers associated with objects.  Implementations <span class="rfc2119">SHOULD</span> avoid reassignment
					of object identifiers within a zone and as the primary home for individual objects may move from one zone to zone over
					time (e.g. a student moving from a middle-school to a high-school zone).</p>
    <a name="AgentApplicationRequirements" />
    <h3>3.3.4 Agent/Application Requirements</h3>
    <p>Each application that wants to be a SIF application, or SIF-enabled application, must have an agent written for it. 
				An agent is an extension to the application that communicates with the ZIS. 
				An agent can be an integral part of an application itself, or may be a separate, specialized client of or interface
				to an application.</p>
    <p>All applications that are part of a SIF zone must be
able to gracefully handle all SIF messages including those messages and data
objects that the application does not support. 
It is <span class="rfc2119">RECOMMENDED</span> that the application return an error <code>SIF_Ack</code> message to the ZIS for those messages 
that the agent does not support (error category Generic Message Handling, error code "Message not supported"). 
An agent <span class="rfc2119">MAY</span> return an "Immediate" <code>SIF_Ack</code> to the ZIS and ignore unsupported messages.</p>
    <p>
					High-level functional requirements for all SIF-enabled applications include the following.
					More detail
					on particular requirements may be found in <a href="Messaging.html">Messaging</a> and <a href="Infrastructure.html">Infrastructure</a>.
				</p>
    <a name="CommunicateWithTheZIS" />
    <h4>3.3.4.1 Communicate with the ZIS</h4>
    <p>Support for <a href="#SIFHTTPSTransport">SIF HTTPS</a> is <span class="rfc2119">REQUIRED</span>  of all agents.
					An agent <span class="rfc2119">MUST</span>  be able to communicate with the ZIS using SIF HTTPS, but
it may attempt to communicate with the ZIS using any communication protocol defined
in this or other specifications. <a href="#SIFHTTPTransport">SIF HTTP</a> is the other communication protocol defined in this specification at this time. 
Support for any communication protocol other than SIF HTTPS is implementation-dependent. 
If connection attempts in protocols other than SIF HTTPS fail, a connection over SIF HTTPS should be made in order for communication to proceed. 
Given the sensitive nature of much of the data within the zone, it is <span class="rfc2119">RECOMMENDED</span>  
						that all communication occur over SIF HTTPS or similarly secure communication protocols.</p>
    <p>Given a communication channel between agent and ZIS, an agent is <span class="rfc2119">REQUIRED</span> to register with the ZIS 
					if it is not already registered or if it wishes to change or retransmit its registration settings. 
					The <code>SIF_Register</code> message provides the ZIS information regarding agent capabilities and requirements, 
					and allows the ZIS to contact the agent in the future if the agent is capable of accepting ZIS-initiated communications (a Push-Mode Agent).</p>
    <p>An agent <span class="rfc2119">MAY</span> also indicate its support for various data objects and associated messages using one or more
					of the <code>SIF_Provision</code>, <code>SIF_Provide</code> and <code>SIF_Subscribe</code> messages.
				</p>
    <a name="TransmitApplicationChangesToTheZIS" />
    <h4>3.3.4.2 Transmit Application Changes to the ZIS</h4>
    <p>When an application makes changes to its data that
correspond to a SIF object it supports, the application <span class="rfc2119">MUST</span> be able to publish <code>SIF_Event</code>s reflecting those data changes. 
If the application/agent makes changes to its data in processing a <code>SIF_Event</code> it has received, it <span class="rfc2119">MUST NOT</span> 
						publish an event that duplicates the changes as described in the processed <code>SIF_Event</code>. 
						Should the application/agent, however, make additional changes beyond those in the <code>SIF_Event</code> being processed, 
						the application <span class="rfc2119">SHOULD</span> generate a new event describing the additional changes.</p>
    <p>If an application does not support an optional field of an object or that element was not changed during the last edit, 
					it <span class="rfc2119">MUST NOT</span> send an empty element, (i.e., &lt;BirthDate/&gt; or &lt;BirthDate&gt;&lt;/BirthDate&gt; ); 
					it <span class="rfc2119">MUST</span> omit the element from the XML stream instead.</p>
    <p>When publishing <code>Add</code> events, Agents <span class="rfc2119">MUST</span> include
all elements listed as mandatory in <a href="DataModel.html">Data Model</a> for the object.</p>
    <a name="RespondToRequests" />
    <h4>3.3.4.3 Respond to Requests</h4>
    <p>All agents <span class="rfc2119">MUST</span> be prepared to handle <code>SIF_Request</code> messages for all objects gracefully.  In the case where an agent
					receives a <code>SIF_Request</code> for an object that it does not support, in addition to acknowledging the
					receipt of the message to the ZIS it <span class="rfc2119">MUST</span> send a <code>SIF_Response</code> message to the Requester with the <code>SIF_Error</code> element populated to indicate 
					the nature of the error (invalid object), a <code>SIF_PacketNumber</code> of <code>1</code> and the <code>SIF_MorePackets</code> element set to indicate that no further packets 
					will be sent in response to the <code>SIF_Request</code>.
					</p>
    <p>If an application agent is a responder for any object, the agent must be prepared to process <code>SIF_Request</code> messages for that object. 
					This involves the ability of the agent to traverse the application database and construct an XML response stream based upon the parameters of the query request.
					All responders <span class="rfc2119">MUST</span> support <code>SIF_Query</code> and query conditions that reference root attributes of the object as well as any mandatory
					elements within the object, along with their mandatory attributes.  Responders <span class="rfc2119">SHOULD</span> support query conditions
					that reference optional elements and their attributes, when the application supports such queries.  Responders <span class="rfc2119">MAY</span>
						support <code>SIF_ExtendedQuery</code> and <span class="rfc2119">MUST</span> register their support for <code>SIF_ExtendedQuery</code>
						using <code>SIF_Provision</code> and/or <code>SIF_Provide</code>.
					</p>
    <p>
						When an agent is creating <code>SIF_Response</code> packets, it <span class="rfc2119">MUST</span> attempt to ensure that each packet is no larger than the
						<code>SIF_MaxBufferSize</code> specified by the <code>SIF_Request</code>.  If for any packet a single packet does fit within the supplied <code>SIF_MaxBufferSize</code>, the agent 
						<span class="rfc2119">MUST</span>,
						in addition to acknowledging receipt of the message to the ZIS, send a <code>SIF_Response</code> message to the Requester with the <code>SIF_Error</code> element populated to indicate
						the nature of the error, and the <code>SIF_MorePackets</code> element set to indicate that no further packets
						will be sent in response to the <code>SIF_Request</code>.
					</p>
    <p>The <code>SIF_Request</code> message also contains <code>SIF_Version</code> elements that specify which SIF versions the responding agent should use when preparing the response packets. 
					If a responding agent can support a single requested SIF version, it returns a response packet using that version.  If more than one version is specified
					and the responding agent supports more than one of those versions it <span class="rfc2119">SHOULD</span> respond with the highest version it supports.
					If the agent cannot support any requested SIF version, in addition to acknowledging receipt of the message to the ZIS, the agent <span class="rfc2119">MUST</span>
						send a <code>SIF_Response</code> message to the Requester with the <code>SIF_Error</code> element populated to indicate the nature of the error, a <code>SIF_PacketNumber</code> of <code>1</code> and the
						<code>SIF_MorePackets</code> element set to indicate that no further packets will be sent in response to the <code>SIF_Request</code>.</p>
    <p>If any other error occurs while creating <code>SIF_Response</code> packets for a given request, in addition to acknowledging receipt of the message to the ZIS,
					the agent <span class="rfc2119">MUST</span> send a <code>SIF_Response</code> message to the Requester with the <code>SIF_Error</code> element populated to indicate the nature of the
					error, with <code>SIF_MorePackets</code> set to indicate that no further packets will be sent in response to the <code>SIF_Request</code>.</p>
    <p>Agents supporting <code>SIF_Request</code>s <span class="rfc2119">MUST</span>  be able to return all of the object fields that the responding application supports or a 
					subset of the fields as 
					specified by the query request. For example, an Agent may request that only a student's graduation year be returned and not the entire <code>StudentPersonal</code> object.
					If the responder does not support a requested element, it <span class="rfc2119">MUST NOT</span> exclude the object from the response stream.  Any
					requested element that is unsupported is omitted from the response stream; when processing <code>SIF_Query</code> requests, parent elements of requested elements, 
					including the object itself, are included in the response stream.
				</p>
    <p>If an application does not support an optional element of an object, it <span class="rfc2119">MUST NOT</span> return an empty element. 
					The element <span class="rfc2119">MUST</span> instead be omitted from the XML stream.</p>
    <a name="ChangesRequiredToTheVendorSApplication" />
    <h4>3.3.4.4 Changes Required to the Vendor's Application</h4>
    <p>Depending upon the type of architecture, the core application may need to be altered to ensure that the agent is able to forward changes to objects of interest to SIF. For example, an application that edits student data may need to be modified to capture the adds, changes, and deletes made to students and store them into a temporary repository until the agent can forward them to the ZIS. Other architectures provide the ability to trap these changes at a server level eliminating the need for any changes to the application itself.</p>
    <p>To meet the SIF requirement of data robustness, it is highly <span class="rfc2119">RECOMMENDED</span> that all changes to objects of interest to SIF 
					be persisted using a database table, local message queue, or other highly reliable storage system. 
					This specification allows for the ZIS and any or all agents to be offline at any given time. 
					Without storing agent changes locally, these changes can be lost when the ZIS is temporarily unavailable; local storage allows these
					changes to be transmitted to the ZIS when it becomes available.</p>
    <p>When an object is shared for the first time in SIF, it is the responsibility of the application making the object available to
					assign its object identifiers/primary keys, typically a RefId in the form of a GUID, before releasing that object to the zone in an <code>Add</code> event or in
					a <code>SIF_Response</code>.  Some application databases are extended to include SIF object identifiers, others maintain
					mappings from SIF object identifiers to locally-defined keys.</p>
    <p>If an application changes data that maps to a SIF object, it is <span class="rfc2119">RECOMMENDED</span> that only the changed fields be sent to the zone. 
					This will result in smaller message sizes and improved performance.</p>
    <p>To avoid unintentional overwriting of data, unsupported fields or fields that have not been changed <span class="rfc2119">MUST NOT</span>  be sent to 
					the zone using empty XML elements, (i.e. &lt;Name Type="04"/&gt; or &lt;Name Type="04"&gt;&lt;/Name&gt; ); 
					the fields <span class="rfc2119">MUST</span> be omitted from the XML stream instead.</p>
    <a name="SupportAuthenticationAndDigitalSignatures" />
    <h4>3.3.4.5 Support Authentication and Digital Signatures</h4>
    <p>Supporting authentication is not a requirement but it is highly <span class="rfc2119">RECOMMENDED</span> to ensure that your agent will be able to communicate with any ZIS. 
					SIF does not mandate the use of authentication, but it is feasible that many SIF implementations will require this functionality. 
					This is especially true for installations that may use the Internet to transport data.</p>
    <p>Typically the authentication and verification mechanisms that are built into the network operating system or transport protocol
					can be leveraged. If these services are available, authentication and verification take place completely within the underlying security package.</p>
    <p>The SIF HTTPS protocol supports authentication between an agent and a ZIS. 
					If authentication is enabled and properly configured, a message receiver (agent or ZIS) can trust the SIF HTTPS implementation 
					to verify that the message in its entirety comes from the claimed sender.</p>
    <a name="AgentLocalQueue" />
    <h4>3.3.4.6 Agent Local Queue</h4>
    <p>An Agent can be developed with a local queuing mechanism so that it can automatically cache incoming messages in a local queue and 
						can acknowledge receipt of each message to the ZIS with "Immediate" <code>SIF_Ack</code> messages
						(which causes the ZIS to remove received messages from the agent's queue). 
					Agents with an Agent Local Queue do not need to send any "Intermediate" <code>SIF_Ack</code>s to the ZIS.
					Use of an Agent Local Queue can be used
						to locally support selective processing of messages, similar to the functionality provided by Selective Message Blocking; its use
						also allows more flexibility and robustness during application/system failure when successfully acknowledging events, requests and/or responses
						before performing the corresponding <code>SIF_Event</code>, <code>SIF_Request</code> and/or <code>SIF_Response</code> handling.</p>
    <p>Agent Local Queue is not a required feature of any Agent. 
						Agent developers can choose not to develop the Agent Local Queue mechanism since this is not part of the compliance requirements 
for the specification at this time.</p>
    <a name="WildcardVersionSupport" />
    <h4>3.3.4.7 Wildcard Version Support</h4>
    <p>It is possible for a SIF Zone to contain Agents written to different versions of the SIF Implementation Specification 
						if a ZIS supports multiple versions in a Zone and has at least one version in common with all registered Agents.
						As such, it is possible for a SIF Zone to contain Agents that have no versions in common with other Agents.
						These Agents consequently have no ability to exchange <code>SIF_Event</code>, <code>SIF_Request</code> or
						<code>SIF_Response</code> messages, unless the ZIS provides message conversion as described in
						<a href="#MultipleVersionZones">"Multiple Version" Zones</a>.</p>
    <p>As message conversion is an implementation-dependent feature of a ZIS, it is <span class="rfc2119">RECOMMENDED</span> that Agents register in Zones and request data using <code>SIF_Version</code> wildcards
						(see <a href="Infrastructure.html#SIF_Register__SIF_Version">SIF_Register</a> for format) that allow for the exchange of data
						between Agents supporting any subset of releases within a major release cycle of this specification (e.g. <code>2.*</code> or <code>*</code>
						to accept any <code>SIF_Message</code> in the 2.x lifecycle).  (Note that <code>*</code> allows messages from 
						any major version to be delivered, which can be structurally quite different across major versions and pose
						development challenges, and is not particularly recommended for indicating the ability to receive messages
						from all versions within a major version release cycle.)  This maximizes the ability of Agents to exchange messages and data in these Zones
						and, for customers, maximizes the utility of Zones supporting different versions of this specification.</p>
    <p>Wildcard version support is particularly important for SIF-enabled applications that are not updated with each release of this specification.  
						Furthermore, given that releases of the SIF Implementation Specification are on
						a more rapid release cycle beginning with version 2.1, typically smaller in scope than SIF Implementation Specification releases historically,
						it is anticipated that it will become more common for SIF-enabled applications in Zones to support different
						specification versions, and for more applications not to be updated with each release of this specification.
						Wildcard version support also allows applications to be SIF-enabled at any time in a SIF Implementation
						Specification major release cycle without risking the need to upgrade with the introduction of a new minor release of the specification,
						particularly when the new functionality offered by the specification does not apply to or impact the application.</p>
    <p>Ignoring revision releases, the changes typical of releases within a given major version are limited to new data objects and optional additions to existing data objects
						(and optional infrastructure additions).  This nature of a lower release being a subset of each higher release within a major
						release lifecycle—and of a higher release being a superset of each lower version—allows SIF-enabled
						applications access to the same elements they rely on at the time of their implementation from SIF messages
						defined by a number of SIF Implementation Specification versions.  For associated implementation notes, see
						<a href="WildcardVersionSupportImplementationNotes.html">Wildcard Version Support Implementation Notes</a>.
						</p>
    <p>While wildcard version support in this specification is only <span class="rfc2119">RECOMMENDED</span>,
						SIF-enabled application developers should be aware that this support may be mandatory in some SIF Certification
						Program product standards <a href="References.html#SIFCertification">[SIFCertification]</a> associated with a major release cycle,
						if application vendors wish to establish their applications as SIF Certified™.</p>
    <a name="ZoneIntegrationServerRequirements" />
    <h3>3.3.5 Zone Integration Server Requirements</h3>
    <p>The Zone Integration Server is the central integration point for all the agents in a zone. 
				Depending on the message type, a ZIS either saves information in the messages that it receives or forwards the messages to other appropriate agents.</p>
    <p>The ZIS implementer is free to internally manage registration and access permissions information in any form that the implementer supports. 
				In order to provide an example of how an administration system may be structured, this document describes a database consisting of an Access Control List
				and Zone Status.</p>
    <a name="AccessControlList" />
    <h4>3.3.5.1 Access Control List</h4>
    <p>A ZIS <span class="rfc2119">MAY</span> maintain access control on whether a zone administrator has granted an agent permissions to register.</p>
    <p>A ZIS <span class="rfc2119">MAY</span> exhibit behavior with regard to the ACL that could be perceived by an Agent as if virtual tables exists 
					defining the following information:</p>
    <a name="Table33511Register" />
    <table title="Register">
      <thead>
        <tr>
          <td>Field</td>
          <td>Comments</td>
        </tr>
      </thead>
      <tr>
        <td>Agent ID</td>
        <td>The unique ID for an Agent (provided as the Source ID in a <code>SIF_Register</code> message)</td>
      </tr>
      <tr>
        <td>Register</td>
        <td>May this agent register in the zone?</td>
      </tr>
    </table>
    <span class="caption">Table 3.3.5.1-1: Register</span>
    <p>An example of this virtual table, which defines which agents are allowed to register in the zone, might be as follows:</p>
    <a name="Table33512VirtualTableExampleRegister" />
    <table title="Virtual Table Example (Register)">
      <thead>
        <tr>
          <td>Agent ID</td>
          <td>Register</td>
        </tr>
      </thead>
      <tr>
        <td>RamseySIS</td>
        <td>true</td>
      </tr>
    </table>
    <span class="caption">Table 3.3.5.1-2: Virtual Table Example (Register)</span>
    <p>In addition, a ZIS <span class="rfc2119">MUST</span> exhibit behavior with regard to the ACL that could be perceived by an Agent as maintaining
						per-context/per-object permissions for each message associated with SIF's Publish/Subscribe and Request/Response models.
						When an agent tries to inquire about a student's personal information, for example, the ZIS needs to check if the agent has the proper permission to
						request such information.  Access control is needed to ensure that the information available in SIF only originates from and
						is accessible by authorized agents.
					</p>
    <a name="Table33513AccessControl" />
    <table title="Access Control">
      <thead>
        <tr>
          <td>Field</td>
          <td>Comments</td>
        </tr>
      </thead>
      <tr>
        <td>Agent ID</td>
        <td>The unique ID for an Agent (provided as the Source ID in a <code>SIF_Register</code> message)</td>
      </tr>
      <tr>
        <td>Context Name</td>
        <td>The name of the SIF Context to which the permissions apply</td>
      </tr>
      <tr>
        <td>Object Name</td>
        <td>The object being manipulated (e.g., <code>StudentPersonal</code>, etc.)</td>
      </tr>
      <tr>
        <td>Provide</td>
        <td>May this Agent register as the provider for this object in this context?</td>
      </tr>
      <tr>
        <td>Subscribe</td>
        <td>May this Agent register as a subscriber for this object in this context?</td>
      </tr>
      <tr>
        <td>Publish "Add" Event</td>
        <td>May this Agent publish "Add" events for this object in this context?</td>
      </tr>
      <tr>
        <td>Publish "Update" Event</td>
        <td>May the Agent publish "Update" events for this object in this context?</td>
      </tr>
      <tr>
        <td>Publish "Delete" Event</td>
        <td>May the Agent publish "Delete" events for this object in this context?</td>
      </tr>
      <tr>
        <td>Request</td>
        <td>May this Agent request this object in this context?</td>
      </tr>
      <tr>
        <td>Respond</td>
        <td>May this Agent respond to a request for this object in this context?</td>
      </tr>
    </table>
    <span class="caption">Table 3.3.5.1-3: Access Control</span>
    <p>It is important to understand that this is a virtual table, defining the appearance of the functionality to the Agents, 
					the actual implementation of this functionality is at the discretion of the implementers of a ZIS.  An example follows:</p>
    <a name="Table33514VirtualTableExampleAccessControl" />
    <table title="Virtual Table Example (Access Control)">
      <thead>
        <tr>
          <td>Agent ID</td>
          <td>Context Name</td>
          <td>Object Name</td>
          <td>Provide</td>
          <td>Subscribe</td>
          <td>Publish "Add" Event</td>
          <td>Publish "Update" Event</td>
          <td>Publish "Delete" Event</td>
          <td>Request</td>
          <td>Respond</td>
        </tr>
      </thead>
      <tr>
        <td>RamseySIS</td>
        <td>SIF_Default</td>
        <td>StudentPersonal</td>
        <td>true</td>
        <td>true</td>
        <td>true</td>
        <td>true</td>
        <td>true</td>
        <td>false</td>
        <td>true</td>
      </tr>
      <tr>
        <td>RamseySIS</td>
        <td>SIF_Default</td>
        <td>LibraryPatronStatus</td>
        <td>false</td>
        <td>false</td>
        <td>false</td>
        <td>false</td>
        <td>false</td>
        <td>true</td>
        <td>false</td>
      </tr>
      <tr>
        <td>…</td>
        <td>…</td>
        <td>…</td>
        <td>…</td>
        <td>…</td>
        <td>…</td>
        <td>…</td>
        <td>…</td>
        <td>…</td>
        <td>…</td>
      </tr>
    </table>
    <span class="caption">Table 3.3.5.1-4: Virtual Table Example (Access Control)</span>
    <p>In addition to access control permission violations, attempts to register any of this functionality with the ZIS
					may fail due to other reasons; e.g. unsupported transport mechanisms, there already being a provider for an object, etc.
					As a result, an Agent <span class="rfc2119">SHOULD</span> be able to gracefully handle corresponding error conditions
					or report those errors to a zone administrator.</p>
    <a name="ZoneStatus" />
    <h4>3.3.5.2 Zone Status</h4>
    <p>
						The ZIS <span class="rfc2119">MUST</span> maintain the status of the zone for implementation purposes, as well as for
						communicating this status to other agents, as defined in <code>SIF_ZoneStatus</code>, when requested.
						This status includes but is not limited to:
					</p>
    <ul>
      <li>product information about the ZIS;</li>
      <li>supported transport protocols, authentication methods and SIF versions;</li>
      <li>supported contexts (see below for more information);</li>
      <li>the currently registered agents, along with applicable registration settings and the current state of each agent; and</li>
      <li>lists of currently registered providers, subscribers, publishers, responders, and requesters.</li>
    </ul>
    <p>
						Providing examples of virtual tables that illustrate storage of all the information associated with <code>SIF_ZoneStatus</code> is beyond the scope of the specification;
						implementers should refer to <a href="Infrastructure.html#SIF_ZoneStatus"><code>SIF_ZoneStatus</code></a> for requirements.
					</p>
    <a name="ZoneContextRegistry" />
    <h4>3.3.5.3 Zone Context Registry</h4>
    <p>Zone Integration Servers <span class="rfc2119">MUST</span>  maintain a registry of the contexts used in each zone in order to perform contextual message routing 
and to populate the <code>SIF_ZoneStatus/SIF_Contexts</code> element. 
This registry will always contain, at a minimum, the official list of contexts defined by the version of SIF that the ZIS supports. 
Beginning with SIF 2.0, that means that each zone will, at a minimum, support the <code>SIF_Default</code> context. 
A ZIS <span class="rfc2119">MAY</span> support allowing additional contexts to be defined within the context registry at the discretion of the ZIS administrator. 
Access Control Lists within each context <span class="rfc2119">MUST</span> also be able to be managed by the ZIS administrator. 
The set of permissions for each agent within each context <span class="rfc2119">MUST</span> be able to be set differently than ACL permissions within a different context for the same agent.</p>
    <p>An agent can obtain a list of all contexts currently defined in a zone by requesting the <code>SIF_ZoneStatus</code> object and enumerating the children of its <code>SIF_Contexts</code> element. 
An agent can determine its ACL permissions within the zone and each context by referring to the <code>SIF_AgentACL</code> object and enumerating the 
permissions and contexts defined within it.</p>
    <a name="Administration" />
    <h4>3.3.5.4 Administration</h4>
    <p>A ZIS <span class="rfc2119">MUST</span> provide an interface for Zone Administrators to configure zone settings, including access control permissions.
					Given the distributed nature of SIF, it is <span class="rfc2119">RECOMMENDED</span> this be a Web-based interface.
					Some of the areas that require administration are:</p>
    <dl>
      <dt>Administration</dt>
      <dd>Start and stop the ZIS and/or set the state of the ZIS to "asleep" or "awake."</dd>
      <dt>
							Security Policies
						</dt>
      <dd>
							A ZIS must provide an interface for administering access control permissions as described above.
						</dd>
      <dd>Administering the minimum <code>SIF_EncryptionLevel</code> for the zone (if only one encryption level is supported, configuration options are unnecessary).</dd>
      <dd>Administering the minimum <code>SIF_AuthenticationLevel</code> for the zone (if only one authentication level is supported, configuration options are unnecessary).</dd>
      <dd>It may also include installing client and server certificate administration.</dd>
      <dt>Zone Settings</dt>
      <dd>
							If the ZIS supports more than one SIF version it must support configuration of which SIF versions
							are used in a zone.
						</dd>
      <dd>
							If the ZIS supports more than one transport protocol, it must allow for configuration of which
							transports agents can use to communicate, including limiting communication to SIF HTTPS.
						</dd>
      <dd>
							The ZIS must support configuration of the minimum acceptable <code>SIF_MaxBufferSize</code> for the zone.
						</dd>
      <dd>If message validation is supported and configurable, configuration to enable or disable message validation in a Zone should be available.</dd>
      <dt>Logging</dt>
      <dd>
							Capture error and message logs to aid in tracking pending, successful and failed delivery of messages.</dd>
      <dt>Reporting</dt>
      <dd>Report zone status and statistics.</dd>
      <dt>Testing</dt>
      <dd>Provide a mechanism to "ping" Push-Mode agents.</dd>
    </dl>
    <a name="SupportSelectiveMessageBlockingSMBToResolveDeadlocks" />
    <h4>3.3.5.5 Support Selective Message Blocking (SMB) to Resolve Deadlocks</h4>
    <a name="Description" />
    <h5>3.3.5.5.1 Description</h5>
    <p>Selective Message Blocking is a feature that <span class="rfc2119">MUST</span>  be implemented by a ZIS to enable 
						non-multitasking agents unable to persist portions of their message queue locally 
						to request information from other Agents while processing a <code>SIF_Event</code> message, 
						without causing communication "deadlock" between an agent and a ZIS.</p>
    <p>This feature allows an agent to inform the ZIS with an "Intermediate" <code>SIF_Ack</code> message that the ZIS must 
						temporarily stop delivering <code>SIF_Event</code> messages to the agent.  The
"Intermediate" <code>SIF_Ack</code> message must not be used by agents in response
to messages other than <code>SIF_Event</code>. The ZIS, however, can deliver other agent-destined messages, <code>SIF_Request</code> and <code>SIF_Response</code>, to this agent. 
After it finishes processing the <code>SIF_Event</code> message this agent sends the "Final" <code>SIF_Ack</code> message to the ZIS, 
which will discard the blocked <code>SIF_Event</code> message and resume normal delivery of all messages, including <code>SIF_Event</code>s.  SMB is supported for both
Push and Pull modes.</p>
    <a name="Requirements" />
    <h5>3.3.5.5.2 Requirements</h5>
    <ul>
      <li>If, after attempting delivery of a <code>SIF_Event</code> message to an agent, the ZIS receives an Intermediate <code>SIF_Ack</code> (<code>SIF_Status/SIF_Code</code>=<code>2</code>) from the agent,
							the event is blocked and all <code>SIF_Event</code> messages destined for the agent, whether already in the queue or that arrive while blocked, are considered frozen. 
							The ZIS will not deliver any <code>SIF_Event</code> messages that are frozen.</li>
      <li>If no <code>SIF_Ack</code> at all is received, or if a transport error occurs, this <code>SIF_Event</code> must be considered an undelivered message. 
							The next message to be delivered to the agent will be this event.</li>
      <li>The ZIS must not deliver another <code>SIF_Event</code> message to the agent until a "Final" <code>SIF_Ack</code> is received (<code>SIF_Status/SIF_Code</code>=<code>3</code>), 
							giving the ZIS permission to discard the original event and resume event delivery. 
							The <code>SIF_OriginalMsgId</code> in the "Final" <code>SIF_Ack</code> <span class="rfc2119">MUST</span> contain the <code>SIF_MsgId</code> of the blocked <code>SIF_Event</code>.</li>
      <li>If <code>SIF_Event</code>s are frozen, the next message to be delivered is the oldest message that is not a <code>SIF_Event</code> message. 
							Once <code>SIF_Event</code>s are unfrozen, all remaining messages in this agent's queue, including <code>SIF_Event</code>s, 
							will be delivered in the order in which they have been received by the ZIS.</li>
      <li>If the ZIS receives a <code>SIF_Wakeup</code> or <code>SIF_Register</code> message then the block on any frozen <code>SIF_Event</code> messages 
							will be removed and the originally blocked message will be the next message delivered to the Agent.</li>
    </ul>
    <a name="Example" />
    <h5>3.3.5.5.3 Example</h5>
    <p>For a detailed example of SMB, see the <a href="SelectiveMessageBlockingSMBExample.html">Selective Message Blocking (SMB) Example</a>.</p>
    <a name="MessageProcessing" />
    <h3>3.3.6 Message Processing</h3>
    <p>To ensure interoperability, SIF defines a set of messages that are exchanged between agents and Zone Integration Servers. The SIF messages are used to perform various operations such as provision, subscription, event reporting, request and response, and ZIS administration.</p>
    <a name="MessageValidation" />
    <h4>3.3.6.1 Message Validation</h4>
    <p>SIF recommends that each message receiver validate any incoming message to ensure that it is a valid SIF message. A message receiver should discard any messages that do not conform to the definition of <code>SIF_Message</code> and return an error to the originator of the message.</p>
    <p>This specification will evolve over time to include new messages and modifications to messages that have been defined. 
Each agent and ZIS should explicitly define which version(s) of the specification they support and validate each incoming message according to its version.</p>
    <p>SIFA provides an XML Schema <a href="References.html#SCHEMA">[SCHEMA]</a> corresponding to this version of the specification for ZIS and agent implementations
					that choose to perform optional message validation. Implementations are free to include additional validation above and beyond the validation capabilities that XML Schema provides.</p>
    <p>The schemas for all versions of this specification are available from SIFA and can be referenced by ZIS and
agent implementations that choose to perform optional message validation. 
This allows implementations to choose schemas based on the particular version in
use by an agent or a ZIS. SIF messages <span class="rfc2119">MUST NOT</span>  be transmitted with hard-coded references to 
DTDs, schemas or other validation mechanisms.  The XML "doctypedecl" (&lt;!DOCTYPE SIF_Message… ) <span class="rfc2119">MUST NOT</span> occur in SIF XML messages,
					nor should <code>xsi:schemaLocation</code> be used on <code>SIF_Message</code>.
				</p>
    <p>The schemas for supported versions of the SIF Implementation Specification enforce ordering of elements and data typing within objects, as per the element
tables given in <a href="Infrastructure.html">Infrastructure</a> and <a href="DataModel.html">Data Model</a>. 
In the event that ZIS and agent implementations choose not to perform message validation, ZIS and agent implementations must still send 
elements as ordered with the types specified in the element tables (i.e., well-formed AND valid XML must be sent for approved objects even if validation is known to be turned off). 
When XML validation is turned off, the sending of draft and locally-defined objects not included in the schemas becomes possible, 
and these objects may experimentally be sent as desired until they make their way into future versions of the specification and supporting schemas.</p>
    <p>ZIS implementations are in the unique position of not only sending messages they themselves formulate; 
					they also forward messages received from agents. 
					When optional message validation is not being performed by a ZIS, 
					it is possible that the ZIS may receive a well-formed but invalid XML message from a non-compliant agent. 
					Under these circumstances, and being the routing mechanism it is, a ZIS is under no obligation to correct an invalid XML message it receives from an agent 
					for delivery to other agents.  Zone administrators can prevent invalid XML messages from being delivered if the ZIS supports message validation
					and they choose to turn that feature on, if configurable.
					Should it receive an invalid but well-formed message from an agent, 
					a ZIS not performing message validation delivers the message like any other to destination agents.</p>
    <a name="MessageIdentification" />
    <h4>3.3.6.2 Message Identification</h4>
    <p>Each message originating from an agent or ZIS needs to
have a message identifier (<code>SIF_MsgId</code>) that is used to identify the
message. In order to eliminate the possibility of duplicated message
identifiers, and to provide a consistent way of generating these identifiers,
SIF requires the use of a globally unique identifier  <a href="References.html#RFC4122">[RFC 4122]</a> as message identifiers.</p>
    <p>The reason that a unique identifier is required is that many messages are handled asynchronously in SIF. 
This means, for example, that <code>SIF_Response</code>s for a given <code>SIF_Request</code> message may not arrive until some time in the future. 
When the <code>SIF_Response</code> arrives, it will contain the original <code>SIF_MsgId</code> but no other information about the original message is guaranteed to be provided. 
The message originator must ensure that it will be able to match up the <code>SIF_Response</code> with the original message based solely on the message identifier.</p>
    <p>For further information concerning
the generation of GUIDs, see <a href="References.html#RFC4122">[RFC 4122]</a>.</p>
    <a name="MessageSecurity" />
    <h4>3.3.6.3 Message Security</h4>
    <p>Because of policy or legislation, providers of extremely sensitive data must never expose that data over an insecure channel. An insecure channel at delivery time is one whose levels of authentication (<code>SIF_AuthenticationLevel</code>) and data encryption (<code>SIF_EncryptionLevel</code>) fall below the values specified by the originating sender. Once the data is communicated to the ZIS, the originator of the message depends upon the ZIS to enforce the security levels requested and the ZIS must not deliver that message to recipient agents using an insecure channel. The originating agent requests the use of a secure channel at delivery time by incorporating a <code>SIF_Security</code> element in the header of the message. The <code>SIF_Security</code> element contains <code>SIF_AuthenticationLevel</code> and <code>SIF_EncryptionLevel</code> elements that define the minimum level of security a data transport channel must provide upon delivery. If a ZIS does not deliver a message due to insufficient security of the connection with a recipient agent, it is recommended that the ZIS log the inability to deliver the message due to security requirements.</p>
    <p>The only SIF messages that currently originate with an agent and that are ultimately delivered to other agents are <code>SIF_Request</code>, <code>SIF_Response</code> and <code>SIF_Event</code>. An originating agent may add a <code>SIF_Security</code> element to all messages, but these three messages are the only ones where <code>SIF_Security</code> will be examined and processed by the ZIS. <code>SIF_Security</code> is used by an originating agent to specify the security requirements of the communication channel between the ZIS and any recipient agent at delivery time. The semantics of including the <code>SIF_Security</code> element on messages other than <code>SIF_Request</code>, <code>SIF_Response</code> and <code>SIF_Event</code> are reserved for future versions of the specification.</p>
    <p>The specification provides several levels of authentication and encryption protection.</p>
    <a name="SIF_AuthenticationLevel" />
    <h5>3.3.6.3.1 SIF_AuthenticationLevel</h5>
    <dl>
      <dt>0</dt>
      <dd>No authentication required and a valid certificate does not need to be presented.</dd>
      <dt>1</dt>
      <dd>A valid certificate must be presented.</dd>
      <dt>2</dt>
      <dd>A valid certificate from a trusted certificate
authority must be presented.</dd>
      <dt>3</dt>
      <dd>A valid certificate from a trusted certificate
authority must be presented and the CN field of the certificate's
Subject entry must match the host sending the certificate.</dd>
    </dl>
    <p>The CN field is more commonly known as the "Common Name" field. <code>SIF_AuthenticationLevel</code> <code>3</code> requires that the CN contents match the host where the message was originated. For instance, a CN entry could be "sifinfo.org" or perhaps "207.95.37.30". If a ZIS at SifInfo.org (IP address 207.95.37.30) contacts an agent at MyAgent.sifinfo.org, the agent's SIF HTTPS transport layer can look at the CN entry in the certificate that was presented by the ZIS and compare it to the actual IP address of the ZIS. <code>SIF_AuthenticationLevel</code> <code>3</code> ensures that not only a valid and trusted certificate was presented but that the agent is actually communicating to the ZIS located at the IP address referenced in the certificate.</p>
    <p>Because security is a cornerstone of the SIF specification,
it is recommended that all ZIS and Agent implementations support client authentication as well as server authentication. When client authentication is being used, the connection first authenticates the server (the party that is being contacted) and if the authentication was successful, the server will request that the client present its certificate for authentication. In this manner, both the ZIS and the agent confirm that they are communicating with the proper parties.</p>
    <p>Since client authentication is not universally available in
all SIF HTTPS implementations, client authentication is only recommended. The need for client authentication is reduced somewhat by using asynchronous message delivery (Push mode) since the ZIS and the agent are both server type applications and will authenticate each other. The need for client authentication is greater for those agents polling for messages (Pull mode) because the ZIS never has to initiate contact with the agent.</p>
    <a name="SIF_EncryptionLevel" />
    <h5>3.3.6.3.2 SIF_EncryptionLevel</h5>
    <dl>
      <dt>0</dt>
      <dd>No encryption required</dd>
      <dt>1</dt>
      <dd>Symmetric key length of at least 40 bits is to be used</dd>
      <dt>2</dt>
      <dd>Symmetric key length of at least 56 bits is to be used</dd>
      <dt>3</dt>
      <dd>Symmetric key length of at least 80 bits is to be used</dd>
      <dt>4</dt>
      <dd>Symmetric key length of at least 128 bits is to be used</dd>
    </dl>
    <p>If a <code>SIF_Request</code>, <code>SIF_Response</code> or <code>SIF_Event</code> is received by the ZIS that does not contain a <code>SIF_Security</code> element, 
the ZIS assigns the lowest level (<code>0</code>) to both the <code>SIF_AuthenticationLevel</code> and <code>SIF_EncryptionLevel</code> requirements for the message, unless
a Zone administrator has configured higher minimum encryption and authentication levels for the Zone. 
This means that the ZIS may distribute this message to any agent that has registered with the ZIS subject to the access control security provisions in place for the zone.</p>
    <p>The lack of a <code>SIF_Security</code> element does not mean that the message will be transported in an insecure manner. Recipient agents communicating with the ZIS over secure channels will receive the message in a secure manner, consistent with the connection. Omitting the <code>SIF_Security</code> element simply allows for those agents that communicate over insecure channels to receive the message, should a zone allow for insecure channels. A zone administrator can prevent messages without <code>SIF_Security</code> elements being communicated over insecure channels by configuring the ZIS and agents in the zone such that a minimum security level is maintained, below which communication is impossible.</p>
    <p>For ZIS and agent implementations that support communication protocols or transport implementations where the security of a channel cannot be determined at delivery time, it is recommended that the zone administrator configure the ZIS and agents in the zone such that a minimum security level is maintained, below which insecure connections cannot be established.</p>
    <a name="NotesOnSIF_AuthenticationLevel" />
    <h5>3.3.6.3.3 Notes on SIF_AuthenticationLevel</h5>
    <p>If authentication based on certificates is being used, care needs to be given to determine if Level 2 (anonymous certificates) will provide the necessary level of protection. With Level 2 authentication, it is possible to use a web browser to make secure connections to the ZIS using the certificates that are built into the browser. This level of authentication is what is used by almost all Internet transactions (stock trading, shopping, financial, etc.). Level 2 does expose the user to a risk of a "man-in-the-middle" attack that can't occur using Level 3 authentication.</p>
    <p>Level 3 mandates that a certificate issued by a trusted authority, (i.e. school district), be installed in the web browser before the browser will be able to connect to the ZIS. This may place unnecessary burdens on the client especially if it is likely that authorized users may wish to connect to the ZIS using a variety of browsers.</p>
    <a name="NotesOnSIF_EncryptionLevel" />
    <h5>3.3.6.3.4 Notes on SIF_EncryptionLevel</h5>
    <p>Weaknesses in a cipher algorithm aside, the major governing factor as to the strength of data encryption is the length of the cipher key. Thus a 128-bit implementation typically provides stronger encryption than an 80-bit implementation. Please note that support of some SIF encryption levels may be subject to export control, limiting distribution of all levels in all countries <a href="References.html#EXPORT">[EXPORT]</a>.</p>
    <p>There are also two main types of cipher algorithms. The first is called a symmetric cipher, which uses the same key to encrypt and decrypt the data. The second type is called public-key cipher, which depends upon using a private key of the sender along with the public key of the receiver. Because of the nature of public-key ciphers, a larger number of bits must be used to achieve a comparable level of encryption strength.</p>
    <p>The <code>SIF_EncryptionLevel</code> bit sizes are based on symmetric ciphers. A table that lists the equivalent key length for a public-key cipher is listed below.</p>
    <a name="Table336341KeyLengths" />
    <table title="Key Lengths">
      <thead>
        <tr>
          <td>Symmetric Key Length</td>
          <td>Public Key Length</td>
          <td>Strength</td>
        </tr>
      </thead>
      <tr>
        <td>40 bits</td>
        <td>256 bits</td>
        <td>Very weak, not recommended except for very minimal protection (i.e. prevents casual snooping but can be broken in minutes by knowledgeable attackers).</td>
      </tr>
      <tr>
        <td>64 bits</td>
        <td>512 bits</td>
        <td>Weak. The current U.S. "standard" has been bumped up to 64 bits from 56 bits but the key length is still weak for sensitive data.</td>
      </tr>
      <tr>
        <td>80 bits</td>
        <td>768 bits</td>
        <td>Moderate</td>
      </tr>
      <tr>
        <td>128 bits</td>
        <td>2048 bits</td>
        <td>Strong, recommended for Internet</td>
      </tr>
    </table>
    <span class="caption">Table 3.3.6.3.4-1: Key Lengths</span>
    <p>For more information regarding this topic, please refer to Chapter 7 of <a href="References.html#Schneier">[Schneier]</a>.</p>
    <a name="MessageRobustness" />
    <h4>3.3.6.4 Message Robustness</h4>
    <p>
            It is important for SIF to guarantee message delivery no matter what happens during delivery of a message, 
            including an unexpected network breakdown or system crash. 
            This requires that each agent and ZIS save each message in permanent storage. 
            At delivery time it is also possible, however, for a ZIS to be prohibited from delivering a message due to security requirements 
            requested by originating agents for individual messages. 
            If this occurs, it is recommended that ZIS implementations discard the affected message so that delivery of other messages may proceed. 
            If the ZIS does discard the message, the ZIS <span class="rfc2119">MUST</span> report a <code>SIF_LogEntry</code> event with the appropriate error category and code, 
            containing a copy of the <code>SIF_Header</code> from the original message. 
            In addition, it is recommended that the ZIS log the delivery failure to its own log.
          </p>
    <p>When a message is delivered under normal circumstances by a ZIS, an agent will return an "Immediate" <code>SIF_Ack</code> or a <code>SIF_Ack</code> with any applicable error condition, signaling the ZIS that it may delete the message from permanent storage. In the case of events, agents may also return an "Intermediate" <code>SIF_Ack</code> to invoke Selective Message Blocking (SMB). In that case, the ZIS will not delete the current <code>SIF_Event</code> from permanent storage until the agent sends a "Final" <code>SIF_Ack</code> to the ZIS.</p>
    <p>When a message is sent to the ZIS under normal circumstances by an agent, the ZIS returns a successful <code>SIF_Ack</code> or a <code>SIF_Ack</code> with any applicable error condition to indicate to the agent that it has in fact received the message and that the agent may delete the message from any permanent storage.</p>
    <p>If a ZIS or agent encounters a transport error in sending a message, it is recommended that the sender retry sending the message. Transport errors where retrying the message is warranted include, but are not limited to, a connection close without a <code>SIF_Ack</code> returned, a transport error or a <code>SIF_Ack</code> with an error category of 10 indicating a connection cannot currently be established, etc. A ZIS in particular must retry delivery of messages from the agent queue until a <code>SIF_Ack</code> that removes the message from the agent's queue is received, subject to certain undeliverable error conditions (e.g. security requirements cannot be negotiated, maximum buffer size too small, etc.). Facing such error conditions, other potentially unresolvable transport errors, or if a <code>SIF_Ack</code> is returned with any other type of error category, the sender may decide not to retry or—when queued, to delete—a message to avoid a potential deadlock condition. Agents returning <code>SIF_Ack</code> messages with error conditions should be aware that such acknowledgements will remove the currently pending message from their delivery queue.</p>
    <a name="MessageCycle" />
    <h4>3.3.6.5 Message Cycle</h4>
    <p>All SIF messages follow the same model. The sender posts a message and receives a <code>SIF_Ack</code> back as a response. The posting of the message by the sender and the receipt of the <code>SIF_Ack</code> from the receiver constitutes one complete cycle. Agents and ZISes can function as senders or receivers, depending on the type of message. The message process is identical, regardless of the type of message being sent.</p>
    <p>If for any reason a sender inadvertently resends a message
with a given <code>SIF_MsgId</code> and the receiver detects this, the receiver may return a
<code>SIF_Status</code> code indicating that it already has the message. This
<code>SIF_Status</code> code is considered a success; the receiver simply discards the
duplicate message and continues handling of the original message.</p>
    <a name="MessageDelivery" />
    <h4>3.3.6.6 Message Delivery</h4>
    <p>There are two models for delivering messages to an agent, "Push" and "Pull." An agent specifies which mode it wants to use when it registers with the ZIS.</p>
    <p>"Push" refers to the action by a ZIS to actively deliver messages to an agent without the agent having to initiate contact with the ZIS. When the ZIS receives a message for an agent and the agent is not in "Sleep" mode; the ZIS will initiate contact with the agent and send the message to the agent.</p>
    <p>"Pull" refers to the action by an agent to explicitly request a single message from the ZIS. When an agent is ready to receive a message, it sends a "Pull" request to the ZIS, to obtain a message that the ZIS has saved in the queue for the agent. After receiving the pull request, the ZIS will examine the agent's queue and either returns a message or a status code indicating that no messages are available for the agent.</p>
    <p>Both modes serve useful purposes. The key requirement is that both an agent and its ZIS must communicate using the SAME mode to avoid potential conflicts.</p>
    <p>
            At delivery time, be it in push or pull mode, a ZIS may encounter messages that it is prohibited from delivering, 
            e.g. due to security requirements requested by originating agents for individual messages, etc. 
            If this occurs, it is recommended that ZIS implementations discard the affected message(s) so that delivery of other messages may proceed. 
            If the ZIS does discard a message, the ZIS <span class="rfc2119">MUST</span> report a <code>SIF_LogEntry</code> event with the appropriate error category and code, 
            containing a copy of the <code>SIF_Header</code> from the original message. 
            <code>SIF_LogEntry/SIF_Desc</code> must contain the SourceId of the agent that has failed to receive the message. 
            In addition, it is recommended that the ZIS log the delivery failure to its own log.
          </p>
    <a name="ThePushModel" />
    <h5>3.3.6.6.1 The "Push" Model</h5>
    <p>When an agent has registered using the "Push" mode, the agent assumes that the ZIS will open a transport connection and send the next available message to the agent. An agent can reply to the sent message with an "Immediate" or optionally—in the case of <code>SIF_Event</code>s—an "Intermediate" <code>SIF_Ack</code>, invoking Selective Message Blocking (SMB); it can also reply using a <code>SIF_Ack</code> with any applicable error condition. "Immediate" or error <code>SIF_Ack</code>s remove the current message from the agent's queue, freeing any remaining or future messages to be delivered to the agent. A "Final" <code>SIF_Ack</code> sent to the ZIS will terminate SMB, removing the frozen event from the agent's queue, freeing any remaining or future messages to be delivered to the agent.</p>
    <a name="ThePullModel" />
    <h5>3.3.6.6.2 The "Pull" Model</h5>
    <p>When an agent has registered using the "Pull" mode, the agent requests a message from the ZIS by sending a <code>SIF_GetMessage</code> message to the ZIS.</p>
    <p>An agent can only issue a <code>SIF_GetMessage</code> to request a message if the agent has previously sent a successful <code>SIF_Register</code> message specifying Pull mode. If the ZIS receives a <code>SIF_GetMessage</code> request and the agent hasn't registered using the Pull mode, the ZIS must return a <code>SIF_Ack</code> containing an error category of Registration and an error code indicating that the agent has registered using Push mode.</p>
    <p>After receiving a <code>SIF_GetMessage</code> request from an agent, the ZIS will return the next message available for delivery to the agent,
subject to Selective Message Blocking. The criteria used to select the message are identical to that used if the ZIS were to Push a message to an agent. </p>
    <p>If a message is available for the agent, the ZIS will return a <code>SIF_Ack</code> message with a <code>SIF_Status/SIF_Code</code> of <code>0</code> and <code>SIF_Status/SIF_Data</code> containing the message from the queue:</p>
    <a name="Example336621ThePullModelSIF_StatusSIF_CodeOf0" />

    <div class="example_parent">
      <div class="example"
>&lt;SIF_Message Version="2.2" xmlns="http://www.sifinfo.org/infrastructure/2.x"&gt;
  &lt;SIF_Ack&gt;
    &lt;SIF_Header&gt;
      &lt;SIF_MsgId&gt;ABCD1058E028D076F083738296372D4E&lt;/SIF_MsgId&gt;
      &lt;SIF_Timestamp&gt;2006-02-18T08:39:40-08:00&lt;/SIF_Timestamp&gt;
      &lt;SIF_SourceId&gt;SifInfo_TestZIS&lt;/SIF_SourceId&gt;
    &lt;/SIF_Header&gt;
    &lt;SIF_OriginalSourceId&gt;RamseySIS&lt;/SIF_OriginalSourceId&gt;
    &lt;SIF_OriginalMsgId&gt;1058ABCDE028D076F083283BC63E6276&lt;/SIF_OriginalMsgId&gt;
    &lt;SIF_Status&gt;
      &lt;SIF_Code&gt;0&lt;/SIF_Code&gt;
      &lt;SIF_Data&gt;
        &lt;SIF_Message Version="2.2"&gt;
          &lt;SIF_Event&gt;
            &lt;SIF_Header&gt;
              &lt;SIF_MsgId&gt;AB34DC093261545A31905937B265CE01&lt;/SIF_MsgId&gt;
              &lt;SIF_Timestamp&gt;2006-02-18T08:39:12-08:00&lt;/SIF_Timestamp&gt;
              &lt;SIF_SourceId&gt;RamseyLib&lt;/SIF_SourceId&gt;
            &lt;/SIF_Header&gt;
            &lt;SIF_ObjectData&gt;
              &lt;SIF_EventObject ObjectName="StudentPersonal" Action="Change"&gt;
                &lt;StudentPersonal RefId="D3E34B359D75101A8C3D00AA001A1652"&gt;
                  &lt;Name Type="04"&gt;
                    &lt;FirstName&gt;William&lt;/FirstName&gt;
                  &lt;/Name&gt;
                &lt;/StudentPersonal&gt;
              &lt;/SIF_EventObject&gt;
            &lt;/SIF_ObjectData&gt;
          &lt;/SIF_Event&gt;
        &lt;/SIF_Message&gt;
      &lt;/SIF_Data&gt;
    &lt;/SIF_Status&gt;
  &lt;/SIF_Ack&gt;
&lt;/SIF_Message&gt;
</div>
    </div>
    <span class="caption">Example 3.3.6.6.2-1: The "Pull" Model - SIF_Status/SIF_Code of 0</span>
    <p>When a pull-mode agent supports multiple SIF specification versions, the version of the <code>SIF_Ack</code> message returned by the ZIS must match the version of any <code>SIF_Message</code> contained in <code>SIF_Status/SIF_Data</code>. For example, if an agent supports versions 1.1 and 1.5 (or 1.*) and the next message in the agent's queue has a <code>SIF_Message/@Version</code> value of <code>1.5</code>, the <code>Version</code> attribute of the <code>SIF_Ack</code> message returned by the ZIS must be <code>1.5</code>, even if the pull-mode agent sent its <code>SIF_GetMessage</code> in a 1.1 <code>SIF_Message</code>. For an agent that supports both 1.1 or later versions and pre-1.1 version(s) (e.g. 1.0r2), when the next message in the agent's queue is from a pre-1.1 agent, the ZIS must return the message in a <code>SIF_Ack</code> message as defined by the pre-1.1 specification.</p>
    <p>A pull-mode agent removes the returned message from its queue in one of three ways. In each case the value for the <code>SIF_OriginalMsgId</code> element in any <code>SIF_Ack</code>(s) created by the agent originates from the <code>SIF_MsgId</code> of the <code>SIF_Message</code> returned as <code>SIF_Data</code> by the ZIS. Typically a pull-mode agent removes the message from its queue by sending an "Immediate" <code>SIF_Ack</code> to the ZIS; an agent may also send a <code>SIF_Ack</code> with any applicable error condition to the ZIS. The ZIS then removes the message from the agent's queue and returns a successful <code>SIF_Ack</code>. If the message is a <code>SIF_Event</code> and the agent wishes to invoke SMB, it can instead notify the ZIS that it is processing the event by sending an "Intermediate" <code>SIF_Ack</code> (which the ZIS acknowledges with a successful <code>SIF_Ack</code>) and later sending a "Final" <code>SIF_Ack</code> when the <code>SIF_Event</code> processing is complete. When the ZIS receives the "Final" <code>SIF_Ack</code>, it removes the <code>SIF_Event</code> from the agent's queue and returns a successful <code>SIF_Ack</code>.</p>
    <p>If there are no messages in the agent's queue that can be delivered, the ZIS will return a <code>SIF_Ack</code> message with a  <code>SIF_Status/SIF_Code</code> of <code>9</code> to indicate that there are no messages available for the agent:</p>
    <a name="Example336622ThePullModelSIF_StatusSIF_CodeOf9" />

    <div class="example_parent">
      <div class="example"
>&lt;SIF_Message Version="2.2" xmlns="http://www.sifinfo.org/infrastructure/2.x"&gt;
  &lt;SIF_Ack&gt;
    &lt;SIF_Header&gt;
      &lt;SIF_MsgId&gt;ABCD1058E028D076F0835E32AC89E048&lt;/SIF_MsgId&gt;
      &lt;SIF_Timestamp&gt;2006-02-18T08:39:40-08:00&lt;/SIF_Timestamp&gt;
      &lt;SIF_SourceId&gt;SifInfo_TestZIS&lt;/SIF_SourceId&gt;
    &lt;/SIF_Header&gt;
    &lt;SIF_OriginalSourceId&gt;RamseySIS&lt;/SIF_OriginalSourceId&gt;
    &lt;SIF_OriginalMsgId&gt;1058ABCDE028D076F08365109BE7C892&lt;/SIF_OriginalMsgId&gt;
    &lt;SIF_Status&gt;
      &lt;SIF_Code&gt;9&lt;/SIF_Code&gt;
    &lt;/SIF_Status&gt;
  &lt;/SIF_Ack&gt;
&lt;/SIF_Message&gt;
</div>
    </div>
    <span class="caption">Example 3.3.6.6.2-2: The "Pull" Model - SIF_Status/SIF_Code of 9</span>
    <a name="MultipleVersionZones" />
    <h5>3.3.6.6.3 "Multiple Version" Zones</h5>
    <p>It is possible for a zone to contain agents written to different versions of the SIF Implementation Specification 
						if a ZIS supports multiple versions in a zone and has at least one version in common with all registered agents. 
						It is possible that two agents in the same zone—both successfully registered—have no version in common, 
						and this affects message delivery by the ZIS in the following manner.</p>
    <p>
							When the next message to be delivered to a given agent has a <code>SIF_Message/@Version</code> attribute that the agent is known not to support, 
							the ZIS cannot successfully deliver that message to the agent without conversion. 
							Should a ZIS implementation choose to convert messages on the fly as a "value-add" feature, it is free to do so; 
							this specification does not prescribe how to convert messages, and support for such conversion is implementation-dependent. 
							However, if the ZIS does not or cannot convert the message such that it can be delivered, 
							it should discard the pending message so that delivery of other messages may proceed. 
							If the ZIS does discard the message, the ZIS <span class="rfc2119">MUST</span> report a <code>SIF_LogEntry</code> event with the appropriate error category and code, 
							containing a copy of the <code>SIF_Header</code> from the original message. 
							<code>SIF_LogEntry/SIF_Desc</code> must contain the SourceId of the agent that has failed to receive the message. 
							In addition, it is recommended that the ZIS log the delivery failure to its own log.
						</p>
    <a name="InfrastructureTransportLayer" />
    <h3>3.3.7 Infrastructure Transport Layer</h3>
    <p>The Infrastructure messages are used by SIF to encapsulate and transfer the data objects. They form a messaging application program interface (API) which is expressed in XML.</p>
    <p>It is a design objective to express the entire
Infrastructure API in XML and not to have dependencies upon any underlying transport layer to provide functionality other than the transportation of the XML from client to server and back. This ensures that the Infrastructure messages can be carried over a variety of communication transports.</p>
    <p>The infrastructure depends upon the transport layer to provide a reliable connection to move messages back and forth from client and server. The transport layer is also responsible for providing data security by means of data encryption and authentication of the client and server. Some transport layers even provide data compression, which is an important factor when processing a large volume of XML messages.</p>
    <p>By delegating the authentication, compression, and encryption to the transport layer, it makes the user interface to the transport simpler. A client that wishes to send an infrastructure message assembles the message in XML and then hands it off to the transport layer for delivery. The transport layer takes the XML message and transfers it to the server where it is taken from the transport layer and processed.</p>
    <p>In moving from the client to the server, the transport may have compressed, encrypted, and authenticated the connections but all of this is transparent to the users of the Infrastructure API. To the user, it is XML in and XML out.</p>
    <p>Different types of transports are or will become available
providing various features and benefits. An Agent or ZIS <span class="rfc2119">MAY</span> employ
multiple transport protocols but they <span class="rfc2119">MUST</span> support SIF HTTPS.</p>
    <p>Please note that throughout this specification transport layer errors are sometimes illustrated as <code>SIF_Ack</code> messages with <code>SIF_Error/SIF_Category</code> of Transport and applicable error codes. Under many transport error conditions, these <code>SIF_Ack</code> messages could not be returned or sent by the remote host. Depending on the SIF infrastructure transport layer implementation these messages may be generated by the implementation (e.g. when a connection to a server cannot be established), or may occur as transport layer errors or exceptions in the underlying network operating system or transport protocol. Both should be treated equivalently.</p>
    <a name="SIFHTTPSTransport" />
    <h4>3.3.7.1 SIF HTTPS Transport</h4>
    <p>In order to ensure that Agents and Zone Integration Servers
can communicate with each other regardless of vendor or platform, all Agent and
ZIS implementations <span class="rfc2119">MUST</span>  support the SIF HTTPS transport layer protocol.</p>
    <p>SIF HTTPS is a combination of the HTTP 1.1 protocol <a href="References.html#RFC2616">[RFC 2616]</a> with secure socket layer (SSL) protocols, 
resulting in an easy-to-use and secure transport protocol. The <span class="rfc2119">RECOMMENDED</span> SSL implementation is 
TLS 1.0 <a href="References.html#RFC2246">[RFC 2246]</a>; however, SSL 3.0 <a href="References.html#SSL3">[SSL3]</a> is also supported 
and SSL 2.0 client hellos <a href="References.html#SSL2">[SSL2]</a> used to negotiate TLS 1.0 or SSL 3.0 connections are also permitted. 
Support for the SSL 2.0 protocol itself—aside from its client hello message—is not provided in SIF. 
Due to the age of the SSL 3.0 and SSL 2.0 protocols and the increasing prevalence of TLS 1.0, 
SIFA expects to deprecate support for the SSL 3.0 protocol and SSL 2.0 client hellos in future major releases of this specification.</p>
    <p>Being based upon HTTP 1.1, the SIF HTTPS and SIF HTTP protocols support persistent or keep-alive connections that greatly increase the message throughput between sender and receiver. This is an especially important factor when using HTTP in conjunction with secure socket layers, where there is a significant amount of overhead when initially opening a connection.</p>
    <p>When using HTTP 1.1 with SIF, <a href="References.html#RFC2616">[RFC 2616]</a> can be used as a reference, however SIF uses a subset of the HTTP 1.1 protocol. For example, only the POST method and the 200-OK response notice are used by the SIF HTTPS protocol.</p>
    <p>Support of Transfer Encoding and data chunking (<a href="References.html#RFC2616">[RFC 2616]</a>,
Section 3.6) is not required for SIF HTTPS. An implementation of
the protocol may support Transfer Encoding and data chunking but it must be able to communicate successfully with a client or server that does not support this feature.</p>
    <p>Because protocol changes are handled at the Infrastructure
XML API level, a client or server must not use the <code>Connection:
Upgrade</code> or <code>Upgrade: xxx</code> headers to invoke a request for a
protocol change. If a client or server receives an upgrade header, it must ignore that header and not change communication protocols.</p>
    <a name="HTTPSRequestResponseModel" />
    <h5>3.3.7.1.1 HTTPS Request/Response Model</h5>
    <p>A client is the party (Agent or ZIS) who initiates a connection to a remote machine. The remote end (ZIS or Push-Mode Agent) is known as the server.</p>
    <p>A client using the SIF HTTPS protocol opens a connection to the server and sends a HTTP 1.1 POST request with the SIF Infrastructure XML message as the POST payload. 
        The server responds with an HTTP response with the Infrastructure XML acknowledgement message as the response payload.
        Clients <span class="rfc2119">MUST</span> encode the XML message using UTF-8; servers <span class="rfc2119">MUST</span> be
        able to process UTF-8-encoded XML and <span class="rfc2119">SHOULD</span> expect 
        all incoming SIF XML messages to be encoded using UTF-8.
</p>
    <p>The default behavior for HTTP 1.1 is to use persistent or
"keep-alive" connections. When operating in this mode, the
client may send additional POST requests and receive the HTTP responses
using the same connection. Clients <span class="rfc2119">SHOULD</span>  use persistent
connections for performance reasons but <span class="rfc2119">MUST</span>  be able to use non-persistent connections if the server does not wish to use persistent connections.</p>
    <a name="HTTPRequestHeaders" />
    <h5>3.3.7.1.2 HTTP Request Headers</h5>
    <p>The following HTTP request and common headers defined in <a href="References.html#RFC2616">[RFC 2616]</a><span class="rfc2119">MUST</span> be present in all SIF HTTPS 
        messages sent by a client:</p>
    <a name="Table337121HTTPRequestHeaders" />
    <table title="HTTP Request Headers">
      <thead>
        <tr>
          <td>Header</td>
          <td>Description</td>
          <td>Required Contents</td>
        </tr>
      </thead>
      <tr>
        <td>Content-Length</td>
        <td>The exact size of the attached payload (XML message)</td>
        <td />
      </tr>
      <tr>
        <td>Content-Type</td>
        <td>Describes the contents of the request. Firewall and web server programs can filter messages going through a network by examining this header.</td>
        <td>application/xml;charset="utf-8"</td>
      </tr>
      <tr>
        <td>Host</td>
        <td>Specifies the Internet host and port number of the destination server</td>
        <td />
      </tr>
    </table>
    <span class="caption">Table 3.3.7.1.2-1: HTTP Request Headers</span>
    <p>Note that all header values <span class="rfc2119">MUST</span> conform to the requirements of <a href="References.html#RFC2616">[RFC 2616]</a> and
        <span class="rfc2119">MAY</span> take equivalent forms subject to those requirements (e.g. <code>application/xml;charset=utf-8</code> (no quotes), 
					<code>application/xml; charset=utf-8</code> (optional spacing), etc.).
      </p>
    <p>In addition to the headers above, a client may
include a <code>Connection: close</code> header in the HTTP request if it
wishes to close the current connection after receiving the response. If
this header is included, the client <span class="rfc2119">MUST NOT</span>  send additional requests on
this connection. The client <span class="rfc2119">MUST</span>  close the connection after receiving the response.</p>
    <p>Clients may also include an "Expect: 100-continue" header (see below).</p>
    <p>Additional headers beyond the required and optional headers listed here <span class="rfc2119">MAY</span>  be included by a client; however,
the server <span class="rfc2119">MUST</span>  be able to successfully process POST requests that only contain the required headers.</p>
    <a name="Example337121SIFHTTPSRequest" />

    <div class="example_parent">
      <div class="example"
>POST /MyPath HTTP/1.1
Content-Length: 420
Content-Type: application/xml;charset="utf-8"
Host: sifinfo.org:8000

&lt;SIF_Message Version="2.2" xmlns="http://www.sifinfo.org/infrastructure/2.x"&gt;
  &lt;SIF_SystemControl&gt;
    &lt;SIF_Header&gt;
      &lt;SIF_MsgId&gt;56409F0C01FBD1C44300B4518E100765&lt;/SIF_MsgId&gt;
      &lt;SIF_Timestamp&gt;2006-04-11T18:18:13-05:00&lt;/SIF_Timestamp&gt;
      &lt;SIF_SourceId&gt;SifInfo_TestAgent&lt;/SIF_SourceId&gt;
    &lt;/SIF_Header&gt;
    &lt;SIF_SystemControlData&gt;
      &lt;SIF_Ping /&gt;
    &lt;/SIF_SystemControlData&gt;
  &lt;/SIF_SystemControl&gt;
&lt;/SIF_Message&gt;
</div>
    </div>
    <span class="caption">Example 3.3.7.1.2-1: SIF HTTPS Request</span>
    <p>Implementations of SIF HTTPS <span class="rfc2119">MUST</span>  be able to specify the value for the path (<code>/MyPath</code> in the example) 
as the Agent or ZIS may require a specific value for routing purposes.</p>
    <a name="HTTPResponseHeaders" />
    <h5>3.3.7.1.3 HTTP Response Headers</h5>
    <p>The following HTTP response and common headers defined in [RFC
2616] must be present in all SIF HTTPS responses messages sent by a server:</p>
    <a name="Table337131HTTPResponseHeaders" />
    <table title="HTTP Response Headers">
      <thead>
        <tr>
          <td>Header</td>
          <td>Description</td>
          <td>Required Contents</td>
        </tr>
      </thead>
      <tr>
        <td>Content-Length</td>
        <td>The exact size of the attached payload (XML message)</td>
        <td />
      </tr>
      <tr>
        <td>Content-Type</td>
        <td>Describes the contents of the request. Firewall and web server programs can filter messages going through a network by examining this header.</td>
        <td>application/xml;charset="utf-8"</td>
      </tr>
      <tr>
        <td>Date</td>
        <td>The current date and time in the format described in RFC 2616 Section 3.3. Note that the date is UTC based and NOT local time.</td>
        <td />
      </tr>
      <tr>
        <td>Server</td>
        <td>Identifies the server sending the response. Clients may use this information to infer information about the server being contacted (vendor, model, version, capabilities, etc.)</td>
        <td />
      </tr>
    </table>
    <span class="caption">Table 3.3.7.1.3-1: HTTP Response Headers</span>
    <p>
          Note that all header values <span class="rfc2119">MUST</span> conform to the requirements of <a href="References.html#RFC2616">[RFC 2616]</a> and
          <span class="rfc2119">MAY</span> take equivalent forms subject to those requirements (e.g. <code>application/xml;charset=utf-8</code>, <code>application/xml; charset=utf-8</code>, etc.).
        </p>
    <p>
          In addition to the headers above, a server <span class="rfc2119">MAY</span>
          include a <code>Connection: close</code> header in the HTTP response if it
          wishes to close the current connection after sending the response. The
          server <span class="rfc2119">MUST</span>  close the connection after sending the response.</p>
    <p>The server <span class="rfc2119">MAY</span>  include additional headers; however, the
client <span class="rfc2119">MUST</span>  be able to successfully process response notices that only contain the required headers and optional header listed here.</p>
    <a name="Example337131SIFHTTPSResponse" />

    <div class="example_parent">
      <div class="example"
>HTTP/1.1 200 OK
Content-Length: 529
Content-Type: application/xml;charset="utf-8"
Date: Mon, 02 Apr 2001 23:32:00 GMT
Server: SIFZIS;V1.1

&lt;SIF_Message Version="2.2" xmlns="http://www.sifinfo.org/infrastructure/2.x"&gt;
  &lt;SIF_Ack&gt;
    &lt;SIF_Header&gt;
      &lt;SIF_MsgId&gt;4A900E10F4E675CF4A01B4518E100765&lt;/SIF_MsgId&gt;
      &lt;SIF_Timestamp&gt;2006-04-11T18:18:13-05:00&lt;/SIF_Timestamp&gt;
      &lt;SIF_SourceId&gt;SifInfo_TestZIS&lt;/SIF_SourceId&gt;
    &lt;/SIF_Header&gt;
    &lt;SIF_OriginalSourceId&gt;SifInfo_TestAgent&lt;/SIF_OriginalSourceId&gt;
    &lt;SIF_OriginalMsgId&gt;56409F0C01FBD1C44300B4518E100765&lt;/SIF_OriginalMsgId&gt;
    &lt;SIF_Status&gt;
      &lt;SIF_Code&gt;0&lt;/SIF_Code&gt;
    &lt;/SIF_Status&gt;
  &lt;/SIF_Ack&gt;
&lt;/SIF_Message&gt;
</div>
    </div>
    <span class="caption">Example 3.3.7.1.3-1: SIF HTTPS Response</span>
    <p>Although the SIF HTTPS protocol uses the 200-OK response
notice to communicate all responses, Agent or ZIS implementations could be
built using existing web server infrastructures. As such, SIF HTTPS
implementations should expect the possible receipt of other HTTP 1.1 response notices.</p>
    <a name="100Continue" />
    <h5>3.3.7.1.4 100 (Continue)</h5>
    <p>This response message status is generally returned if the
client has included an <code>Expect: 100-continue</code> header in its
request. Certain web server implementations return a 100 (Continue)
status response even though the original request did not contain an
<code>Expect: 100-continue</code> header. When a client receives an
unexpected response with a 100 (Continue) status, it must discard that response and wait for a subsequent final (e.g. 200-OK) response. 
Clients explicitly requesting a 100 (Continue) status response by including an <code>Expect: 100-continue</code> header in a 
request should proceed with the request body according to section 8.2.3 of the HTTP 1.1 <a href="References.html#RFC2616">[RFC 2616]</a> 
          specification upon receipt of the 100 (Continue) status response.</p>
    <p>A SIF HTTPS client may include an <code>Expect: 100-continue</code> header but generally does not. 
        If it does, however, servers (ZIS and push-mode agent implementations) must handle the header according to section 8.2.3 of the HTTP 1.1 <a href="References.html#RFC2616">[RFC 2616]</a> specification, possibly returning an intermediate response with 100 (Continue) status, for communication to proceed correctly.</p>
    <a name="3XX4XX5XXNotices" />
    <h5>3.3.7.1.5 3XX, 4XX, 5XX Notices</h5>
    <p>A server should only return 200-OK response notices
but may return other notices. Servers built using existing web
server technology are more likely to return other types of response
notices. If a client receives any 3xx, 4xx, or 5xx response notices, it must treat these responses as if a transport error has occurred.</p>
    <a name="SIFHTTPTransport" />
    <h4>3.3.7.2 SIF HTTP Transport</h4>
    <p>The SIF HTTP protocol is identical to the SIF HTTPS transport without a secure socket layer to provide data encryption and authentication.</p>
    <p>An Agent or ZIS <span class="rfc2119">MAY</span> implement the SIF HTTP transport but <span class="rfc2119">MUST</span> implement the SIF HTTPS protocol.</p>
    <p>Because of the sensitive data being exchanged in SIF, it is <span class="rfc2119">RECOMMENDED</span> that only SIF HTTPS be used.</p>
    <a name="SIFHTTPSTransportCompression" />
    <h4>3.3.7.3 SIF HTTP(S) Transport Compression</h4>
    <p>
			It is possible that compression can improve network throughput in SIF implementations where large amounts of data are transferred over SIF HTTP(S), either horizontally or vertically.
			The HTTP 1.1 specification <a href="References.html#RFC2616">[RFC 2616]</a> allows for negotiating the content encoding (and compression) of server responses using
			the <code>Accept-Encoding</code> request header and the <code>Content-Encoding</code> response header.  Registered content encodings include in
			addition to the default uncompressed <code>identity</code> encoding a number of compressed encodings: <code>gzip</code>, <code>compress</code>
			and <code>deflate</code>.  A client can specify one or more encodings to use in a response along with its preference for each using <code>Accept-Encoding</code>,
			and the
			server responds accordingly, per the HTTP specification.  If the server does not support a requested encoding, it is recommended the server return a
			<code>406 (Not Acceptable)</code> status code.</p>
    <a name="Example33731SIFClientRequestingCompressionOfResponse" />

    <div class="example_parent">
      <div class="example"
>POST /MyPath HTTP/1.1
Content-Length: 420
Content-Type: application/xml;charset="utf-8"
Accept-Encoding: gzip
Host: sifinfo.org:8000

&lt;SIF_Message Version="2.2" xmlns="http://www.sifinfo.org/infrastructure/2.x"&gt;
...
&lt;/SIF_Message&gt;
</div>
    </div>
    <span class="caption">Example 3.3.7.3-1: SIF client requesting compression of response</span>
    <a name="Example33732SIFServerReturningCompressedSIF_Ack" />

    <div class="example_parent">
      <div class="example"
>HTTP/1.1 200 OK
Content-Length: 24
Content-Type: application/xml;charset="utf-8"
Content-Encoding: gzip
Date: Wed, 25 Apr 2007 23:32:00 GMT
Server: SIFZIS

...compressed SIF_Ack...
				
</div>
    </div>
    <span class="caption">Example 3.3.7.3-2: SIF server returning compressed SIF_Ack</span>
    <p>The content encoding of any HTTP entity body, either in a request or a response, is indicated using the <code>Content-Encoding</code> header,
			which is considered a modifier to the <code>Content-Type</code> header.
			A client may compress or apply an encoding to the body of an HTTP request and indicate it has done so with an appropriate <code>Content-Encoding</code>
			value.  It is recommended that a server that cannot or will not accept a particular encoding return a <code>415 (Unsupported Media Type)</code>
			status code.</p>
    <a name="Example33733SIFClientSendingCompressedSIF_Message" />

    <div class="example_parent">
      <div class="example"
>POST /MyPath HTTP/1.1
Content-Length: 149
Content-Type: application/xml;charset="utf-8"
Content-Encoding: gzip
Host: sifinfo.org:8000

...compressed SIF_Message...
				
</div>
    </div>
    <span class="caption">Example 3.3.7.3-3: SIF client sending compressed SIF_Message</span>
    <a name="Example33734SIFClientSendingCompressedSIF_MessageAndRequestingCompressionOfResponse" />

    <div class="example_parent">
      <div class="example"
>POST /MyPath HTTP/1.1
Content-Length: 149
Content-Type: application/xml;charset="utf-8"
Content-Encoding: gzip
Accept-Encoding: gzip
Host: sifinfo.org:8000

...compressed SIF_Message...
				
</div>
    </div>
    <span class="caption">Example 3.3.7.3-4: SIF client sending compressed SIF_Message and requesting compression of response</span>
    <p>With these HTTP-defined headers, SIF Agents and Zone Integration Servers have the ability to compress or negotiate compression of 
			SIF HTTP(S) request and response entity bodies using any
			version of SIF where the transport protocol is SIF HTTPS or SIF HTTP.  However, to increase interoperability of Agents and Zone Integration Servers that
			wish to compress requests or receive compressed responses beyond the level of trial and error in an environment where server
			status codes are not guaranteed, the following mechanisms were developed in SIF Implementation Specification Version 2.1.</p>
    <a name="SIF_ProtocolSIF_PropertyAcceptEncoding" />
    <h4>3.3.7.4 SIF_Protocol/SIF_Property Accept-Encoding</h4>
    <p>In both <code>SIF_Register</code> and <code>SIF_ZoneStatus</code> the following <code>SIF_Property</code> is defined when used in
			conjunction with a <code>SIF_Protocol/@Type</code> value of <code>HTTPS</code> or <code>HTTP</code>:</p>
    <table>
      <thead>
        <tr>
          <th>
            <code>SIF_Name</code>
          </th>
          <th>
            <code>SIF_Value</code>
          </th>
        </tr>
      </thead>
      <tbody>
        <tr>
          <td>
            <code>Accept-Encoding</code>
          </td>
          <td>An <code>Accept-Encoding</code> header value as per HTTP 1.1 <a href="References.html#RFC2616">[RFC 2616]</a>.</td>
        </tr>
      </tbody>
    </table>
    <p>This property indicates that an HTTP(S) server can accept corresponding content encodings with an appropriate <code>Content-Encoding</code> header value.</p>
    <a name="Example33741SIF_ProtocolWithAcceptEncodingIndicatingAcceptanceOfGzipAndIdentity" />

    <div class="example_parent">
      <div class="example"
>&lt;SIF_Protocol Type="HTTPS" Secure="Yes"&gt;
  &lt;SIF_URL&gt;https://www.sifinfo.org/sifagent/MyAgent/&lt;/SIF_URL&gt;
  &lt;SIF_Property&gt;
    &lt;SIF_Name&gt;Accept-Encoding&lt;/SIF_Name&gt;
    &lt;SIF_Value&gt;gzip&lt;/SIF_Value&gt;
  &lt;/SIF_Property&gt;
&lt;/SIF_Protocol&gt;
</div>
    </div>
    <span class="caption">Example 3.3.7.4-1: SIF_Protocol with Accept-Encoding indicating acceptance of gzip (and identity)</span>
    <a name="Example33742SIF_ProtocolWithAcceptEncodingIndicatingNoAcceptanceOfEncodingsOtherThanGzipOrIdentityGzipPreferredOverIdentity" />

    <div class="example_parent">
      <div class="example"
>&lt;SIF_Protocol Type="HTTPS" Secure="Yes"&gt;
  &lt;SIF_URL&gt;https://www.sifinfo.org/sifagent/MyAgent/&lt;/SIF_URL&gt;
  &lt;SIF_Property&gt;
    &lt;SIF_Name&gt;Accept-Encoding&lt;/SIF_Name&gt;
    &lt;SIF_Value&gt;gzip;q=1.0, identity;q=0.5, *;q=0&lt;/SIF_Value&gt;
  &lt;/SIF_Property&gt;
&lt;/SIF_Protocol&gt;
</div>
    </div>
    <span class="caption">Example 3.3.7.4-2: SIF_Protocol with Accept-Encoding indicating no acceptance of encodings other than gzip or identity, gzip preferred over identity</span>
    <p>The recommended compression algorithm for use in SIF is <code>gzip</code>.  It is <span class="rfc2119">NOT RECOMMENDED</span>
			that the <code>identity</code> (uncompressed) encoding ever be explicitly excluded in the <code>Accept-Encoding</code> <code>SIF_Property</code>.</p>
    <a name="HTTPClientRequirements" />
    <h4>3.3.7.5 HTTP Client Requirements</h4>
    <p>A client (ZIS, Push- or Pull-Mode Agent) that wishes to receive a compressed response <span class="rfc2119">MUST</span> include an <code>Accept-Encoding</code> header,
			per HTTP 1.1, and <span class="rfc2119">MUST</span> be prepared to handle a <code>406 (Not Acceptable)</code> or other HTTP error, in which
			case the client <span class="rfc2119">SHOULD</span> assume compression using the specified algorithm(s) is not supported and retry communication as per <a href="#SIFHTTPSTransport">SIF HTTPS Transport</a>
			or <a href="#SIFHTTPTransport">SIF HTTP Transport</a> above.  Clients <span class="rfc2119">MUST</span> be prepared to receive <code>identity</code>-encoded
			(unencoded) responses unless the client explicitly excludes <code>identity</code> in its <code>Accept-Encoding</code> header, which is <span class="rfc2119">NOT RECOMMENDED</span>.</p>
    <p>Zone Integration Servers <span class="rfc2119">MAY</span> consult a Push-Mode
			Agent's registered <code>SIF_Protocol/SIF_Property</code> value where <code>SIF_Name</code> is <code>Accept-Encoding</code> before contacting
			the Agent and <span class="rfc2119">SHOULD</span> assume that posting a corresponding encoded entity body accompanied by the applicable <code>Content-Encoding</code>
			header value will be processed without content encoding support errors by the Agent.</p>
    <p>Push- and Pull-Mode Agents <span class="rfc2119">MAY</span> consult a Zone's supported compression algorithms in
			the <code>SIF_ZoneStatus/SIF_SupportedProtocols/SIF_Protocol/SIF_Property</code> entitled <code>Accept-Encoding</code> in <code>SIF_Name</code>
			before contacting the Zone Integration Server and <span class="rfc2119">SHOULD</span> assume that posting a corresponding encoded entity body accompanied by the applicable <code>Content-Encoding</code>
			header value will be processed without content encoding support errors by the ZIS.</p>
    <a name="HTTPServerRequirements" />
    <h4>3.3.7.6 HTTP Server Requirements</h4>
    <p>A server (ZIS or Push-Mode Agent) that receives an HTTP request with an <code>Accept-Encoding</code> header <span class="rfc2119">MUST</span> process the request
			per HTTP 1.1's <code>Accept-Encoding</code> specification.  It is <span class="rfc2119">RECOMMENDED</span> that servers return a
			<code>406 (Not Acceptable)</code> status when a requested encoding cannot be negotiated.</p>
    <p>A server that receives an HTTP request with a <code>Content-Encoding</code> header specified <span class="rfc2119">MUST</span>
			process the request per HTTP 1.1's <code>Content-Encoding</code> specification.  It is <span class="rfc2119">RECOMMENDED</span> that
			servers unable to process a particular content encoding return a <code>415 (Unsupported Media Type)</code> status code.</p>
    <a name="PushModeAgentRequirements" />
    <h4>3.3.7.7 Push-Mode Agent Requirements</h4>
    <p>A Push-Mode Agent that wishes to receive compressed/encoded requests from the ZIS <span class="rfc2119">MUST</span> register its preference
			with the ZIS in the <code>SIF_Register/SIF_Protocol</code> property entitled <code>Accept-Encoding</code> in <code>SIF_Name</code>, providing
			an <code>Accept-Encoding</code> value in <code>SIF_Value</code> per HTTP 1.1 (the recommended compression algorithm for SIF is <code>gzip</code>).  
			The Agent
			<span class="rfc2119">MUST</span> be prepared to handle an error <code>SIF_Ack</code> from the ZIS when registering <code>Accept-Encoding</code>
			(<code>SIF_Error/SIF_Category</code> of <code>5</code> [Registration], <code>SIF_Error/SIF_Code</code> value of <code>10</code>) if the ZIS
			cannot support at least one specified encoding
			and <span class="rfc2119">SHOULD</span> re-attempt registration without <code>Accept-Encoding</code>.</p>
    <p>Upon successful registration of an <code>Accept-Encoding</code> value, the Agent <span class="rfc2119">SHOULD</span> expect to receive
			requests from the ZIS encoded accordingly, but it <span class="rfc2119">MAY</span> received <code>identity</code>-encoded (unencoded)
			requests unless <code>identity</code> was explicitly excluded in the registered <code>Accept-Encoding</code> value.</p>
    <a name="ZoneIntegrationServerRequirements" />
    <h4>3.3.7.8 Zone Integration Server Requirements</h4>
    <p>A Zone Integration Server that receives a <code>SIF_Register/SIF_Protocol/SIF_Property</code> named <code>Accept-Encoding</code> in <code>SIF_Name</code>
			must fail the attempt to register if the ZIS does not support at least one of the specified encodings
(<code>SIF_Error/SIF_Category</code> of <code>5</code> [Registration], <code>SIF_Error/SIF_Code</code> value of <code>10</code>).  While this property is typically registered
			by Push-Mode Agents, Pull-Mode Agents may also specify this property when registering.  A ZIS <span class="rfc2119">SHOULD</span> compress requests
			when contacting a Push-Mode Agent if the Agent has previously registered that preference, but it <span class="rfc2119">MAY</span> send uncompressed
			requests if the Push-Mode Agent did not explicitly exclude the <code>identity</code> encoding in its registered <code>Accept-Encoding</code> value.</p>
    <p>Zone Integration Servers that support handling of compressed/encoded requests <span class="rfc2119">SHOULD</span> return an <code>Accept-Encoding</code>
			header <code>SIF_Value</code> in the <code>SIF_ZoneStatus/SIF_SupportedProtocols/SIF_Protocol/SIF_Property</code> named <code>Accept-Encoding</code> in <code>SIF_Name</code>.</p>
    <div class="navigation" id="bottomnavigation">
      <hr />
      <a href="index.html">home</a>
      <a href="Introduction.html">previous</a>
      <a href="Messaging.html">next</a>
      <a href="index.html#contents">table of contents</a>
    </div><p align='center'><a href='http://validator.w3.org/check?uri=referer'><img src='http://www.w3.org/Icons/valid-xhtml10' alt='Valid XHTML 1.0 Transitional'/></a></p></body>
</html>